Nick Brown wrote:
> Currently if the environmental variable is not set then
> DEBUGGER_START_FILE defaults to this;
>
> configure.in: DEBUGGER_START_FILE=
> ${ac_default_prefix}/lib/bashdb/bashdb-main.inc
>
> However looking at the bashdb package Makefiles I note that
> bashdb-main.inc will be found in $(datadir)/bashdb/, thus I think
> DEBUGGER_START_FILE should default to that instead of
> ${ac_default_prefix}/lib/
>
> Simply changing this to;
>
> configure.in: DEBUGGER_START_FILE=${datadir}/bashdb/bashdb-main.inc
>
> does not quite work as pathname.h ends up looking like this;
>
> #define DEBUGGER_START_FILE "${prefix}/share/bashdb/bashdb-main.inc"
>
> but I'm sure someone that understands autoconf/automake better can
> correct this.
After reading section 4.7.2 "Installation Directory Variables" of the autoconf
manual (see below), realise this is because pathnames.h is generated at
configure time, but sould be generated at make time, by a makefile snippet.
Does anyone know how to do this for? (or I'm going to need to learn autotools
a lot more)
Cheers,
Nick
<--snip-->
Most of these variables have values that rely on prefix or exec_prefix. It is
deliberate that the directory output variables keep them unexpanded:
typically [EMAIL PROTECTED]@' will be replaced by `${prefix}/share', not
`/usr/local/share'.
This behavior is mandated by the GNU coding standards, so that when the user
runs:
`make'
she can still specify a different prefix from the one specified to
configure, in which case, if needed, the package shall hard code dependencies
corresponding to the make-specified prefix.
`make install'
she can specify a different installation location, in which case the
package must still depend on the location which was compiled in (i.e., never
recompile when `make install' is run). This is an extremely important
feature, as many people may decide to install all the files of a package
grouped together, and then install links from the final locations to there.
In order to support these features, it is essential that datadir remains being
defined as `${prefix}/share' to depend upon the current value of prefix.
A corollary is that you should not use these variables except in Makefiles.
For instance, instead of trying to evaluate datadir in `configure' and
hard-coding it in Makefiles using e.g.,
`AC_DEFINE_UNQUOTED(DATADIR, "$datadir")', you should add
`-DDATADIR="$(datadir)"' to your CPPFLAGS.
Similarly you should not rely on AC_OUTPUT_FILES to replace datadir and
friends in your shell scripts and other files, rather let make manage their
replacement. For instance Autoconf ships templates of its shell scripts
ending with `.in', and uses a Makefile snippet similar to:
edit = sed \
-e 's,@datadir\@,$(pkgdatadir),g' \
-e 's,@prefix\@,$(prefix),g'
autoconf: Makefile $(srcdir)/autoconf.in
rm -f autoconf autoconf.tmp
$(edit) $(srcdir)/autoconf.in >autoconf.tmp
chmod +x autoconf.tmp
mv autoconf.tmp autoconf
autoheader: Makefile $(srcdir)/autoheader.in
rm -f autoheader autoheader.tmp
$(edit) $(srcdir)/autoconf.in >autoheader.tmp
chmod +x autoheader.tmp
mv autoheader.tmp autoheader
Some details are noteworthy:
[EMAIL PROTECTED]@'
The backslash prevents configure from replacing [EMAIL PROTECTED]@' in the
sed
expression itself.
`$(pkgdatadir)'
Don't use [EMAIL PROTECTED]@'! Use the matching makefile variable instead.
`,'
Don't use `/' in the sed expression(s) since most likely the variables you
use, such as `$(pkgdatadir)', will contain some.
`Dependency on `Makefile''
Since edit uses values that depend on the configuration specific values
(prefix etc.) and not only on VERSION and so forth, the output depends on
`Makefile', not `configure.ac'.
`Separated dependencies and Single Suffix Rules'
You can't use them! The above snippet cannot be (portably) rewritten as:
autoconf autoheader: Makefile
.in:
rm -f $@ [EMAIL PROTECTED]
$(edit) $< >[EMAIL PROTECTED]
chmod +x [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
See section 10.10 Limitations of Make, for details.
``$(srcdir)''
Be sure to specify the path to the sources, otherwise the package won't
support separated builds.
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
