Re: including autoconf paths in source

[Monty Taylor]

John Calcote wrote:
> Ralf,

First of all... thanks guys...

> The trouble with your approach is that it doesn't solve the original
> poster's issue. The issue was that when such variables are expanded into
> config.h using the regular AC_DEFINE mechanism, environment variables
> don't get expanded in the variable substitution:
> 

-- snip --

> I've tried multiple methods for accomplishing this same thing, and there
> are only two reasonable approaches that I've discovered -- both have
> been mentioned already, but I'll summarize:
> 
> 1. Use variable substitution on the compiler command line, as shown
> above. This is fine for a small number of such substitutions, but
> rapidly becomes unwieldy when more than 3 or 4 are required - command
> lines grow very long. Additionally, as has been pointed out, it becomes
> difficult to generate unit tests etc, as all compiler command lines must
> contain appropriate substitutions.

This is what we've been doing so far. It's not terrible, but it does
make for a rather long and ugly command line. In and of itself this
isn't a problem, but when trying to scan through output to see where you
are or what's going it, it does get noisy.


> 2. Use sed (or awk, or perl, or whatever) to generate a source file from
> a meta-source file:

And this is what I'm now doing... albeit with something like this:

configmake.h: Makefile
        @rm -f address@hidden $@
        @{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
          echo '#define PREFIX "$(prefix)"'; \
          echo '#define EXEC_PREFIX "$(exec_prefix)"'; \
etc.

I need to add a thing in there like already happens with config.h -
where it actually does that into a .configmake.h.new or something and
then diffs the two and only replaces the old one if the new one is
different...

I'm wondering if it would be worthwhile to add an AC_DEFINE form, like
AC_DEFINE_EXPANDED, that would fully-expand things before putting them
in config.h... the discussion leads me to believe I am, in fact, not the
only person to have run in to this. :)

Monty

> --- snip ---
> 
> foo.sh: foo.sh.in Makefile
>       sed -e "s,address@hidden@],$(localedir)," \
>       < $(srcdir)/foo.in > foo.sh
>       chmod +x foo.sh.in
> 
> --- snip ---
> 
> The advantage of the second approach is that it generates proper values
> at the proper time. All variables may still be defined on the compiler
> command line by the user, as the substitution doesn't occur until just
> before the file is actually compiled. The disadvantage is that the build
> process is now encumbered by an additional translation - from
> meta-source to source - at least for one of the source files.
> 
> Regards,
> John
> 
> Ralf Corsepius wrote:
>> On Fri, 2008-12-12 at 07:52 -0500, Thomas Dickey wrote:
>>   
>>> On Fri, 12 Dec 2008, Ralf Corsepius wrote:
>>>
>>>     
>>>>> compiler, or test-application).  Putting them in the generated config.h
>>>>> doesn't run into that problem.
>>>>>         
>>>> Only if done properly.
>>>>       
>>> I agree (of course: putting them into the generated config.h is assumed
>>> to be "done properly").
>>>     
>> This approach typically trips directory expansion problems. It's bad
>> advise to new-comers
>>
>>   
>>>   For the rest - your example doesn't address the
>>> specific case I had in mind,
>>>     
>> Which? Or course, the details vary in specific cases, nevertheless this
>> trick is pretty mighty.
>>
>>   
>>>  so it's perhaps useful advice for another
>>> topic.
>>>     
>> automake's toplevel configury applies this trick - It's borrowed from
>> there ;)
>>
>> Ralf
>>  
>>
>>
>>
>> _______________________________________________
>> Autoconf mailing list
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/autoconf
>>
>>   
> 
> 
> 
> _______________________________________________
> Autoconf mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/autoconf
>