[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [automake] Dependency question with _LDADD

From: Michel Briand
Subject: Re: [automake] Dependency question with _LDADD
Date: Wed, 8 Oct 2008 20:13:53 +0200

Peter Johansson <address@hidden> - Wed, 08 Oct 2008 10:41:42 -0400

>Hi Michel,
>Michel Briand wrote:
>> Peter Johansson <address@hidden> - 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/
>>>> internal_version.c: ${top_srcdir}/PROGRAM_VERSION
>>>>    ${top_srcdir}/ $(component) $(VERSION) < $(templ) > $@
>>>> training_SOURCES = training.c internal_version.c
>>>> The 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 `', 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 
>>> 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, 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 
>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:

But one can imagine other schema...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]