[MERGE] Re: bzr version-info for C/C++
John Arbash Meinel
john at arbash-meinel.com
Tue Oct 9 18:20:20 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Lukáš Lalinský wrote:
> On 10/6/07, Panagiotis Papadakos <papadako at csd.uoc.gr> wrote:
>> Well the bzr version-info with python and rio support is already in
>> bzr.dev. So why we shouldn't add c format support to it?
>
> I agree with this. C/C++ is used by vast majority of open source
> project, I don't see a reason to not have it in bzr core.
>
> Lukas
>
I wrote the original version-info code, and the Rio and Python formats.
And I felt I should comment as to why I didn't include C/C++. (I do, in
fact, use it in some of my projects.)
The specific reason is because I wanted to be able to have multiple
version files in the same large project (each library would have its
own), and thus I needed a way to have namespaces for my values.
These were the templates I used (they are a little dated because I
adapted them from back when I was using Arch, before Bazaar (in either
form) existed).
version_hpp_template = """/** %(version_hpp_name)s
* This file was automatically generated by generate_version.py
*
* It was generated by running it from inside the arch tree, so
* don't try to regenerate it from CVS.
*
* Also, you probably shouldn't edit it, since it is likely to
* be recreated.
*
* The only reason it is saved in CVS is because you can't regenerate
* it without arch.
*/
#ifndef %(define)s
#define %(define)s
%(expanded_namespace)s
extern const char *revision;
extern const char *build_date;
extern const char *date;
extern const char *branch_nick;
extern const char *version;
extern const int revno;
extern const bool clean;
%(namespace_closure)s // end namespace %(namespace)s
#endif // %(define)s
// vim: ts=4 sw=4 noexpandtab si
"""
version_cpp_template = """/** %(version_cpp_name)s
* This file was automatically generated by generate_version.py
*
* It was generated by running it from inside the arch tree, so
* don't try to regenerate it from CVS.
*
* Also, you probably shouldn't edit it, since it is likely to
* be recreated.
*
* The only reason it is saved in CVS is because you can't regenerate
* it without arch.
*/
#include "%(version_hpp_name)s"
const char *%(namespace)s::revision = "%(revision)s";
const char *%(namespace)s::build_date = "%(build_date)s";
const char *%(namespace)s::date = "%(date)s";
const char *%(namespace)s::branch_nick = "%(branch_nick)s";
const char *%(namespace)s::version = "%(version)s";
const int %(namespace)s::revno = %(revno)s;
const bool %(namespace)s::clean = %(clean)s;
// vim: ts=4 sw=4 noexpandtab si
"""
My build scripts were in Scons, so it was easy enough to have the python
interpreter run "bzr version-info --format=python" and directly
interpret the result. And then I would also read *another* file that
would give me stuff like the "namespace", etc.
Some of it was the idea of taking the C++ namespace "mf::framework" and
translating that into:
#ifndef _MF_FRAMEWORK_VERSION_HPP_
#define _MF_FRAMEWORK_VERSION_HPP_
namespace mf { namespace framework {
extern const char *revision;
...
} }
...
mf/framework/version.cpp:
#include "mf/version/version.hpp"
const char *mf:framework:revision = "john at arbash-meinel.com-2007020234";
...
With python, you get a namespace just by putting it into a file. So I
can do "import mf.framework.version" and get everything separated into
its own little space.
Anyway, I'm curious what people think about having extended support in
version-info for parsing a source file to determine extra information
(namespace/etc) to include to generate the template.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHC7hUJdeBCYSNAAMRAmHbAKDWWNbwwIem+IX2RLDKyhUj/OMAZACggvgE
mVppDuv6Qru058I3jP4jgxQ=
=wiks
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list