autoconf
[Top][All Lists]
Advanced

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

Re: optional features and AC_ARG_WITH


From: Paul Eggert
Subject: Re: optional features and AC_ARG_WITH
Date: Thu, 03 Feb 2005 15:40:22 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Gregorio Guidi <address@hidden> writes:

> As you can imagine, a very common (if not the most common) use case for code 
> in configure.in/configure.ac is the following: run a check, see the result, 
> and decide if a specific feature of the software should be enabled or 
> disabled.

I think the most common use for configure.ac is to test for features
of the underlying platform, not for whether user-visible features are
enabled.  The former is the focus of most Autoconf macros; the latter
is the focus of AC_ARG_ENABLE.

> it is very important when creating a package to know in advance what
> features will be enabled in the software at the end of the process,
> without knowing the details of the host where the package is
> building.

When you say "features", do you mean "user-visible features"?  That is
the subject tof AC_ARG_ENABLE, and you can control them with the
appropriate --with* options when you invoke ./configure.

Or do you mean platform features?  Is the problem that people are
building on one platform, and expecting the result to run on a
slightly different platform, and it doesn't work?  And that you want
to tell ./configure "Please assume we're running on a platform that
has only a subset of the features that you can discover by running on
the build platform."?  Well, one way you can do that is to put the
appropriate values into the environment before running ./configure;
and another way is to cross-compile for the more-limited environment;
but I suspect that I don't fully understand your problem yet.

> So I'm asking: could it be a good idea as a long-term solution to
> advertise among software developers the adoption of some
> standardized macro that could make it easier to add configure
> switches, such as the macros that I'm attaching below?

Offhand I don't see the advantage over AC_ARG_ENABLE.  Or another way
to put it is, if we're already having trouble with developers not
using AC_ARG_ENABLE when they should, then why won't we have the same
problem with the new macros you're proposing?




reply via email to

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