[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:57:27 +0200

Peter Johansson <address@hidden> - Wed, 08 Oct 2008 14:39:26 -0400

>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.
>>>>> 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 ;).
>Ok, now you really confused me. Your looked like:
>internal_version.c: ${top_srcdir}/PROGRAM_VERSION
>       ${top_srcdir}/ $(component) $(VERSION) < $(templ) > $@
>but you meant $(PROGRAM_VERSION), right? What I wanna get to, is that it looks 
>like you set the variable for the program version at configure time. If (!) 
>that is true, it implies you need to run configure every time you change file 
>`PROGRAM_VERSION'. That is no problem, but since you seem to be eager to avoid 
>such dependencies you could avoid that by reading the file at make time 
>instead. Something like this:
>internal_version.c: ${top_srcdir}/PROGRAM_VERSION ${top_srcdir}/ 
> $(templ)
>       program_version=`echo ${top_srcdir}/PROGRAM_VERSION` && \
>       ${top_srcdir}/ $(component) $$program_version < $(templ) > $@

Sorry for the confusion ! Its my fault

I would not have chosen "VERSION" for my variable in since
it duplicates one predefined variable (configure).

I should have named it "MY_VERSION", or better

The variable is dynamic. Make will read the file every time.

# Main program: training
# Uses libtraining in ../lib



internal_version.c: $(PV)
    ${top_srcdir}/vtempl $(component) \
    $(TRAINING_PROGRAM_VERSION) < $(templ) > $@


bin_PROGRAMS = training
training_SOURCES = training.c internal_version.c
training_LDADD = ../lib/


I don't really need to depend on since, if this script
respect its basic semantic, we don't mind the implementation changes.

The internal_version.c file does contains only the program's version :
I don't see the need for a dependency on, neither. But you
maybe have something in mind ?


reply via email to

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