autoconf
[Top][All Lists]
Advanced

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

Re: including autoconf paths in source


From: John Calcote
Subject: Re: including autoconf paths in source
Date: Fri, 12 Dec 2008 10:09:37 -0700
User-agent: Thunderbird 2.0.0.18 (X11/20081112)

Ralf,

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 ---

prefix= /usr/local
datarootdir= ${prefix}/share
localedir = ${datarootdir}/locale

To get localedir into a source file, I've got a section in Makefile.am like:

DEFS = -DLOCALEDIR="\"$(localedir)\"" @DEFS@

(except that I've actually got several - localedir is just a convenient
example) It makes things a little ugly.

If I just do AC_DEFINE(LOCALEDIR,"${localedir}") I only get
#define LOCALEDIR "${datarootdir}/locale"

--- snip ---

As you can see, the problem was that LOCALEDIR becomes
"${datarootdir}/locale" in the expansion, rather than what the poster
wanted: "/usr/local/share/locale".

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.

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

--- 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
>
>   





reply via email to

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