autoconf
[Top][All Lists]
Advanced

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

mozilla configury [sorry for not replying]


From: Paolo Bonzini
Subject: mozilla configury [sorry for not replying]
Date: Tue, 20 May 2003 12:19:20 +0200
User-agent: Mutt/1.4i

> Autoconf 2.5x requires that macros only be called once which screws up 
> the cross-compiling checks and some other conditional library checks. 
> When building a specific version of the browser (say against gtk2), we 
> don't want to check for unneeded libraries (like gtk1 or qt).  I still 
> don't understand why conditional checks are frowned upon especially when 
> some of them (like AC_PROG_CXX) will stop the script if they fail.

This is not always true at the same level in different autoconf 2.5x
versions.  Conditional checks for unneeded libraries in any case are
not as frowned upon as conditional checks for tools.  I don't understand
the point WRT AC_PROG_CXX (isn't Mozilla itself written in C++?), which
other tests abort configure?

> There appears to be no mechanism in autoconf 2.5x to allow extra 
> arguments to be passed down to sub-configures.  This is needed for 
> Mozilla as several of the libraries in cvs are released as standalone 
> libraries and we need to pass options down from the toplevel configure 
> to configure those sub-builds to suit the browser build.

You can do this with ac_configure_args:

m4_define([MOZ_SET_CONFIGURE_ARG], [
case $ac_configure_args in
  *$1*) ;;
  *) ac_configure_args="$ac_configure_args $1" ;;
esac])

> The toplevel Mozilla configure script contains a hack to generate a
> mozilla-config.h header from any AC_DEFINEs which were called
> during configure.  (Yes, there should have been a mozilla-config.h.in
> file, don't get me started.)  Recently, that hack was hacked to allow
> modules to have their own individual module-config.h headers.

This does not seem hard to port (but man, it's brittle!).

However, with Autoconf 2.5x this might be made unnecessary by
autoheader's revamping and by its tracing of configure.in's actual
expansion process (as Akim puts it, don't trust anything but m4 to
parse m4!).

mozilla-config.h.in should be generated more or less correctly by
autoheader except for variables in the AC_DEFINE'd name: in which
case, take a look at the implementation of AC_CHECK_FUNCS to see
how to properly invoke AH_TEMPLATE for the benefit of autoheader.

Paolo




reply via email to

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