Re: Using agvtool's generated version info file?
Re: Using agvtool's generated version info file?
- Subject: Re: Using agvtool's generated version info file?
- From: Christiaan Hofman <email@hidden>
- Date: Mon, 16 Aug 2010 14:35:45 +0200
On Aug 16, 2010, at 14:22, Rainer Brockerhoff wrote:
> At 13:52 +0200 16/08/10, Christiaan Hofman wrote:
>> On Aug 16, 2010, at 13:35, Rainer Brockerhoff wrote:
>>> So you can access those constants by including
>>> extern const unsigned char XYZVersionString[];
>>> extern const double XYZVersionNumber;
>>> in the file where you want to access them, and the linker will find them for you.
>>
>> The fact that they exist and you can do that does not mean that you SHOULD have a use for them (and that's what I said, I never said you can't). AFAIK they're there only to have these symbols in the binary, for debugging purposes. They're not meant for actual use. Otherwise there would be a header file to advertise them, or at least some documentation.
>
> There can't be a fixed header file as the names change (your project name is a prefix). I agree that one use is to have the version string visible in the binary.
>
> Anyway, the agvtool man page documents this, and I now remember that that's where I found it originally years ago:
>> To enable Apple Generic Versioning, then, you must set up at least the VERSIONING_SYSTEM and
>> CURRENT_PROJECT_VERSION project build settings for each project you want to be versioned. The target
>> of a versioned project will have two global variables generated and linked into your product. One is
>> of type double and is simply the CURRENT_PROJECT_VERSION. The other is a version string which is for-matted formatted
>> matted to be compatible with what(1). These variables are available for use in your code.
> ...note last sentence: "These variables are available for use in your code"...
>
Pretty lame if they don't tell you how and their variable naming scheme. That would warrant a documentation bug, I'd say.
>
>> So really my reply should be: why WOULD you want that?
>
> When I used this, I wanted to have the build number (which is what I used the version field for) available early in main.c, without accessing other files or making assumptions about bundle files. I also had some plain c helper tools which needed the same info.
> --
> Rainer Brockerhoff <email@hidden>
> Belo Horizonte, Brazil
> "In the affairs of others even fools are wise
> In their own business even sages err."
> Blog: http://brockerhoff.net/blog
OK, that makes sense. Thanks
Christiaan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden