[MERGE] Re: bzr version-info for C/C++

Lukáš Lalinský lalinsky at gmail.com
Tue Oct 9 19:44:11 BST 2007


On 10/9/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
> John Arbash Meinel has voted tweak.
> Status is now: Conditionally approved
> Comment:
> I'm okay with this, though I would like to make a few comments.
>
> a) #define is probably the most common way to do this sort of thing, but
> I personally prefer "const char*" variables. Because you can refer to
> them, and look them up in a debugger, they are always compiled into the
> source, etc. I suppose users can do:
>
> version.c:
>
> #include "autogenerated_version.h"
>
> const char *revision_id = VERSION_INFO_REVISION_ID;
>
> b) We don't have any way to give the version strings any sort of unique
> name/namespace, etc. You don't need it in python, because every file is
> a namespace. *I* would like to see a way to add some way to have
> multiple versions in a large project. Imagine having 3 libraries and a
> main program all independently versioned. You version variables/defines
> step on eachother's toes. I'm not sure how to do it for C code, but we
> could end up with a C++ version that uses the built-in namespace
> functionality.

Well, I decided to use #defines instead of const char * variables for
exactly this reason - to defer namespace issues to the developer. If
you compile two files with included different version-info header
files with const char *revision_id you will get a symbol conflict,
because such variables will be always included in the object file and
will have the same name. But if you do the same thing with #defines,
everything is fine, because you decide which values should be included
in the object file and how they should be named. Or you can even do
things like:

const char *version_info_str = "Foo, version 1.2.3 (rev "
VERSION_INFO_REVNO ")";

Lukas



More information about the bazaar mailing list