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

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

 



Stefano Sabatini wrote:
> I'm working on a project when I have a Perl script, call it "script",
> which contains some installation dependant paths.
>
> Since I don't want to hardcode them, I created a "script.in" file, which
> contains a line with:
>
> my $system_config_file= "@SYSCONF_DIR@/script.conf";
>
> and placed this snippet in configure.ac:
>
> dnl $sysconfdir contains "${prefix}/etc, so I have to
> dnl eval it another time
> eval "eval SYSCONF_DIR=$sysconfdir"
>
> AC_SUBST(SYSCONF_DIR)
>
> AC_CONFIG_FILES(script)
> 
> This works mainly as expected, but in the script file I get:
>
> my $system_config_file= "NONE/etc/pac.conf";
>                          ^^^^
>
> What am I missing?

Autoconf initialises `prefix=NONE', then resets it to what the user gave
as the `--prefix=/some/path' argument.  If the user doesn't specify such
an argument, then it remains set as `NONE' to the end of the configure
script, eventually being replaced by `prefix=$ac_default_prefix' in
config.status, just before generating the AC_CONFIG_FILES; this allows
your configure script to check, at any time, whether or not the user
specified `--prefix=/some/path', (e.g. with `test "$prefix" = NONE',
although AFAIK this feature is undocumented).

To work around it, you have two options:--

1) Defer the extra `eval' to your generated script, so expanding that
   embedded ${prefix} reference when your own script is run.

2) Use a hairy construct in configure.ac, such as:--

   my_sysconfdir=`test "$prefix" = NONE && prefix=$ac_default_prefix;
     eval echo "${sysconfdir}"`
   AC_SUBST([my_sysconfdir])

   (hairy, because AFAIK $ac_default_prefix is undocumented).

> Another question: in the case it's possible to get this working, is it
> a standard/recommended technique (I see examples using simply sed
> translations in the Makefile to achieve the same effect)?

It comes down to whatever best suits the build infrastructure you've
established for you own project.  My own preference is to let autoconf
handle as much of the platform dependent variance as possible, and keep
the makefiles relatively simple.

HTH,
Keith.


_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf

[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux