Re: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET
Hello Rhys, * Rhys Ulerich wrote on Thu, Jul 02, 2009 at 05:22:27PM CEST: I've got a macro that needs $target_cpu which is available from AC_CANONICAL_TARGET. Within my macro I use AC_REQUIRE([AC_CANONICAL_TARGET]) which triggers the following warning: configure.ac:47: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET ../../lib/autoconf/general.m4:1723: AC_CANONICAL_TARGET is expanded from... m4/acx_mkl.m4:64: ACX_MKL is expanded from... configure.ac:47: the top level The easy way to eliminate the warning is to include AC_CANONICAL_TARGET early on in my configure.ac. Yes, and in this case, that seems to be the right way to me. However, I'd like to have the macro strictly enforce the requirement of AC_CANONICAL_TARGET because I anticipate putting it up on the Autoconf macro archive once it gets a bit more mature. Are there any recommended ways to rectify the warning under that use case? Why do you think it would be a problem for users of your macro to follow the above advice? The current Autoconf code doesn't mangle program names in the right way otherwise. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
ACLOCAL_FLAGS
Hello! Here's something I've not found really discussed anywhere so far, which I find kind of surprising. Would you accept a patch which made 'autoreconf' honour an 'ACLOCAL_FLAGS' variable? I ask because I'm working on jhbuild (GNOME build script tool). Most autogen.sh scripts run 'aclocal $ACLOCAL_FLAGS', and so jhbuild sets this environment var - using it so autoconf macros that have been installed by packages in its sandbox directory are visible to subsequent packages it's building. Now some autogen.sh scripts are changing to just run 'autoreconf' and that breaks this behaviour. I can't see any easily solutions other than what I proposed, modifying autoreconf to take an env var 'ACLOCAL_FLAGS' into account .. it's great that autogen.sh scripts are becoming wrappers around autoreconf (since otherwise, there's no point having autoreconf :) but without an easy way of passing the m4 include path there's no point. Running 'autoreconf -I /home/sam/prefix/share/aclocal' doesn't work by the way, I assume this alters the path for some other components. Thanks for input on this! Sam ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: ACLOCAL_FLAGS
On Friday 03 July 2009 17:53:30 Sam Thursfield wrote: Here's something I've not found really discussed anywhere so far, which I find kind of surprising. Would you accept a patch which made 'autoreconf' honour an 'ACLOCAL_FLAGS' variable? I ask because I'm working on jhbuild (GNOME build script tool). Most autogen.sh scripts run 'aclocal $ACLOCAL_FLAGS', and so jhbuild sets this environment var - using it so autoconf macros that have been installed by packages in its sandbox directory are visible to subsequent packages it's building. Now some autogen.sh scripts are changing to just run 'autoreconf' and that breaks this behaviour. I can't see any easily solutions other than what I proposed, modifying autoreconf to take an env var 'ACLOCAL_FLAGS' into account .. it's great that autogen.sh scripts are becoming wrappers around autoreconf (since otherwise, there's no point having autoreconf :) but without an easy way of passing the m4 include path there's no point. Running 'autoreconf -I /home/sam/prefix/share/aclocal' doesn't work by the way, I assume this alters the path for some other components. does setting ACLOCAL_AMFLAGS in Makefile.am not work ? it seems to work in all my projects. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
