Gregorio Guidi <greg_g@xxxxxxxxxx> 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? _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
