[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting at path to AC_CONFIG_AUX_DIR
From: |
Ralf Wildenhues |
Subject: |
Re: Getting at path to AC_CONFIG_AUX_DIR |
Date: |
Tue, 12 Aug 2008 23:24:39 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello Rhys,
* Rhys Ulerich wrote on Thu, Aug 07, 2008 at 07:55:37PM CEST:
>
> I'm putting together a (hopefully reusable) macro the requires a script in
> my AC_CONFIG_AUX_DIR directory:
>
> AC_DEFUN(AC_FOOBARBAZ,[
> #...
> AC_REQUIRE([AC_CONFIG_AUX_DIR_DEFAULT])
> AC_REQUIRE_AUX_FILE([tex-it])
> AC_SUBST(ac_aux_dir)
> # Output a script that will later invoke $(ac_aux_dir)/tex-it during Make
> #...
> ])
>
> This is a little klunky. Is there a better way to get of the configured
> AC_CONFIG_AUX_DIR than hijacking ac_aux_dir with AC_SUBST?
That is indeed klunky. I'm afraid you won't be able to get by without
undocumented Autoconf (or Automake) features at all; but the above is a
bit inconvenient. First, please AC_SUBST a different variable (which
you initialize from ac_aux_dir), second, without mangling the value is
unusable from subdirectories of the build directory. Ideally, I guess
Autoconf should provide a public variable that is mangled for each
subdir (like it currently does with $INSTALL, $MKDIR_P).
Automake does
am_aux_dir=`cd $ac_aux_dir && pwd`
to absolutify its value. You can do this, but it prevents building from
a source directory with spaces in its name. (You can't have both, a
possibly relative path but without spaces, and a path that is constant
for all Makefiles.) This is a bit tricky code (we've gotten previous
instances of similar code wrong repeatedly), and I'm too tired to
venture into it right now.
* Eric wrote:
> > What's wrong with doing this in configure.ac:
> >
> > AC_CONFIG_AUX_DIR([build-aux])
> >
> > then doing this in your Makefile:
> >
> > aux_dir=$(top_srcdir)/build-aux
> > ...
> > rule:
> > $(SHELL) $(aux_dir)/tex-it
Apart from the other items already discussed, this only runs in the
toplevel Makefile.
> I'm trying to insulate myself against breakage if/when someone changes the
> build-aux directory name. It looked like the usual Autoconf missing
> install-sh logic used AC_CONFIG_AUX_DIR_DEFAULT to handle this. Just
> wondered if there's any public mechanism to handle this.
There should be, eventually.
> Also, generally, how do people package/distribute support scripts (like my
> $(aux_dir)/tex-it) when posting stuff up to the various Autoconf macro
> archives?
This is another problem that should be solved, eventually. Currently
most other packages either just let the user copy a file, or they have
extra scripts to install such stuff (libtoolize, gettextize,
gnulib-tool, ...), yuck. automake has --add-missing, maybe one should
just teach it to look for extra files in a standard place.
I'd personally prefer to leave all this stuff to post 2.63.
Cheers,
Ralf