This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: How to install "config.h"
- To: Simon Richter <Simon dot Richter at phobos dot fachschaften dot tu-muenchen dot de>
- Subject: Re: How to install "config.h"
- From: Raja R Harinath <harinath at cs dot umn dot edu>
- Date: 27 Oct 2000 15:08:13 -0500
- Cc: Mark Galassi <rosalia at galassi dot org>, Ossama Othman <ossama at valinor dot ece dot uci dot edu>, automake at gnu dot org
- List-Id: Discussion list for automake <automake.gnu.org>
- References: <Pine.LNX.4.21.0010272118200.12410-100000@phobos.fachschaften.tu-muenchen.de>
Simon Richter <Simon.Richter@phobos.fachschaften.tu-muenchen.de> writes:
> On 27 Oct 2000, Mark Galassi wrote:
> [Installing config.h]
>
> > But be careful: if any of the C code in the package itself includes
> > <your-package-name/config.h> you might be in for a nasty surprise: if
> > a version is already installed and a user is compiling a new version
> > from source, that user will pick up the installed .h files which will
>
> Even more evil: These files will contain definitions for PACKAGE and
> VERSION.
And unless the configure.in tests are exactly the same, you'll have
HAVE_* conflicts.
Compare (on Solaris)
AC_CHECK_LIB(resolv, inet_aton) #define HAVE_RESOLV 1
AC_CHECK_FUNC(inet_ntoa) #define HAVE_INET_NTOA
vs.
AC_CHECK_LIB(resolv, inet_aton, RESOLV_LIB=-lresolv) #define HAVE_RESOLV 1
AC_CHECK_FUNC(inet_ntoa) #undef HAVE_INET_NTOA
(I know, in "reasonable" circumstances, this example won't really
cause problems, even with both config.h being included.)
And, then we have the problem of having anything depending on the
output of config.status going into $prefix rather than $exec_prefix.
- Hari
--
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions." -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing." -- Roy L Ash