autoconf
[Top][All Lists]
Advanced

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

Re: How to substitute variables in script files? (Why is $prefix set to


From: Stefano Sabatini
Subject: Re: How to substitute variables in script files? (Why is $prefix set to NONE?)
Date: Fri, 2 Mar 2007 10:37:30 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On date Thursday 2007-03-01 23:15:30 +0100, Andreas Schwab configured this 
message:
> Stefano Sabatini <address@hidden> writes:
> [CUT] 
> These substitutions are designed to be used in a makefile where the
> variables are recursively expanded.
> 
> > Unfortunately it's rather ad-hoc solution and not very clear from the
> > point of view of the script.in reader, and it's not applicable to
> > other scripting languages that don't support that particular
> > shell-like syntax (e.g. lisp).
> 
> For other languages besided makefiles it is recommended to do the
> substitution not during configuration, but at build time using the
> recursively expanded values in the makefile.
> 
> [CUT]
> 
> The problem with this approach is that the value is not recursively
> expanded.  The second level expansion could still refer to other
> variables.  For example, a recent addition to autoconf is the datarootdir
> variable, and datadir is now defined in terms of datarootdir, which in
> turn is defined in terms of prefix.  A two level expansion of datadir will
> no loger lead to a fully expanded value.

I finally ended up in this way, with a rule in the Makefile.in that says:

script: script.in
        sed -e 's|__SYSCONFDIR__|$(sysconfdir)|' \
            -e 's|__PACKAGE_NAME__|@PACKAGE_NAME@|' \
            -e 's|__PACKAGE_VERSION__|@PACKAGE_VERSION@|' script.in > script

where I designed a special notation for all the variables in the script that
will be expanded at build time, to avoid conflicts with the original
content of the script.

This definitively resolves the N-level expansion problem (expansion is
performed in the Makefile), and maybe it's more straigthforward than
the other approaches.

Thanks all for the replies.

Cheers
-- 
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)




reply via email to

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