Peter Johansson <[EMAIL PROTECTED]> - Wed, 08 Oct 2008 10:41:42 -0400
>Hi Michel,
>
>Michel Briand wrote:
>> Peter Johansson <[EMAIL PROTECTED]> - Tue, 07 Oct 2008 11:21:26 -0400
>>
>>
>>> Hello Michel,
>>>
>>> Michel Briand wrote:
>>>
>>>> Hi all,
>>>>
>>>> I implemented a new idea for program's version.
>>>>
>>>> In src/bin/Makefile.am:
>>>>
>>>> internal_version.c: ${top_srcdir}/PROGRAM_VERSION
>>>> ${top_srcdir}/vtempl.pl $(component) $(VERSION) < $(templ) > $@
>>>>
>>>> training_SOURCES = training.c internal_version.c
>>>>
>>>> The vtempl.pl Perl program takes a template as input and filter it to
>>>> produce the internal_version.c source file.
>>>>
>>>> Each time the PROGRAM_VERSION file will be changed, the new source file
>>>> will be regenerated, then the build system will recompile it, and
>>>> relink the program.
>>>>
>>>>
>>> The source file will be regenerated only if PROGRAM_VERSION is changed,
>>> though. I would add the template file, the perl script `vtempl.pl', and
>>> `Maskefile' in the list of dependencies.
>>>
>>> I don't know what your perl script looks like or what it achieves, but I
>>> could imagine you could achieve something similar with a simple sed
>>> call. See chapter 4.8.2 in autoconf manual for an example
>>> http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables
>>> Thereby you could avoid the requirement that users need perl to build
>>> your package.
>>>
>>
>> Yes. You're right ;). I join my perl script. But also a sed script to
>> replace it ;).
>>
>Ok, I thought of having the sed call within the Makefile.am, but your
>way is perhaps preferable...
>
>>> Also, what is the reason you don't want to use config.h?
>>>
>>>
>>
>> Other source files in the project should not be affected by a change of
>> the VERSION.
>>
>> A simple use case when you have you're projet in configuration
>> management.
>>
>> a) You prepare the version 2.1 of the project (you have "2.1pre9" in the
>> file PROJECT_VERSION). You finish you're work (code, build, test, ...)
>> and commit.
>>
>> b) The integration step comes in, and extract your 2.1pre9 source,
>> build it, and test it.... With numerous tools that will check static or
>> dynamic states of the program...
>>
>> c) Integration step finishes well and we are ok to release. But we'll
>> keep the generated files (object, executable) in configuration. So we
>> don't want to rebuild the tree after all tests have passed. So we do
>> not want to change the PROGRAM_VERSION if we know that it'll change
>> config.h => rebuilt the tree...
>>
>> The main point here is that we have tests that run a lot of time. And
>> that we can change the PROGRAM_VERSION according to the configuration
>> management or the release policy. It's not in the source dependency
>> field ;).
>>
>> Anyway we want the program to be dependant of the version since it's
>> embedded. So I've a dependency to relink it.
>>
>> Is my explanation enough clear/detailed ?
>>
>Ok. Got your point. One question though. Where do you read the file
>PROGRAM_VERSION?
>
>Is the info in PROGRAM_VERSION somehow propagated through variable
>$(VERSION)? But I thought $(VERSION) always was set in AC_INIT?
>
VERSION defined by configure in config.h will be the package's version
(as a whole).
I'll not use it ;).
Since the package can include a library and a program. Each one could
have its own version.
So in ${top_srcdir} I create one file per usefull version:
PROGRAM_VERSION
LIBRARY_VERSION
But one can imagine other schema...
Cheers,
Michel
