Re: Maintainer friendly mode for autotools projects

[Steffen Dettmer]

On Thu, Feb 12, 2009 at 7:59 PM, Ivan Levashew
<address@hidden> wrote:
> Generally, I'd like build system and compiler to be as humble
> as possible.  Don't run tests on my platform, don't look for
> libraries and headers in my /usr directory. If something is not
> specified by means of command line or environment variables, it
> doesn't exist. The only exception is libraries/headers provided
> by compiler (which is specified on command line anyway). OS
> headers should be taken from SDKs and never from my system.

I'm not sure how it looks in your context, but I think usually
autoconf expects to be able to create a binary which usually
requires at least some libc.

Or are you compiling a libc itself?

> It really annoys me that so many accidents can happen!

(yes, my favorite is when cross compiling and ending up with
 /lib/cpp and detecting amazing POSIX headers in minimalistic
 embedded environments :-))

> The problem is that ./configure scripts either measure my OS or
> guess values (not always correct) or abort configuration. How
> can I control this process?  I'd like ./configure to retrieve
> values from a knowledge base.

How should the knowledge base (I assume it would be some
delivered file) know what libraries a user has and wants to use?
For instance, when someone uses a different C library that your
package likes most but also has the one you are assuming, the
user sets up his system to make his favorite the default.
(A core idea, AFAIK, is that autoconf leaves most possible
 decisions to the user)

> In abscense of such kb, there should be an option to generate
> all the measurement scripts so that I could send them to
> testers. Also, there must be an option to populate KB out of
> measurement results. Whether the feature is supported
> everywhere, nowhere or its support varies.

I think the idea of autoconf is to check whether a feature is
supported or not. When you have a test checking whether ANSI C /
ISO C headers are available it should work in any case on a
correctly configured system (well, as long as no /lib/cpp
fallback is performed ;)).
Unfortunately, for cross compiling possibilities because usually
test binaries cannot be run.

Well, I'm not sure if the assumption that a binary can be linked
(which must be true for cross compiling checks) is always
correct. If you have no ANSI-C, there might be no such thing as
main() and even worse, trying to use main() may lead to errors
(which could be considered a bug in the cross compiler
environment / installation, and I think its difficult to support
this correctly with autoconf).

There is also a thread here about running cross compiling
binaries. I think, personally, if (as suggested in the thread) a
binary can simply run by running it, it should not be called
cross-compiling. I have no clue how to use simulators, like
additionally specifying some "wrappers" to be used for running
(like prefixing with "armsd $ARMSD_OPTS" or alike) and if it is
possible to have a slightly different setup [for instance, I need
to link with a special libc to be able to use armsd]).

I think in the end this practically means that is it not possible
to do everything in autoconf. There are aspects that have to be
covered in implementations with some not-so-nice #ifdefs (like
when you have a buggy snprintf implementation when cross
compiling).

> Most of the tutorials spot the light on user friendly mode, which isn't very
> helpful for me. Pieces of essential (for me) information are scattered
> through the darkest corners of documentation, but I think there should be
> lots of people like me demanding reliable maintainer environment.

I think for builing source and binary packages, a clean release
build environment is neccesary.

For binary packages it is easy: on this environment there must be
not library installed that the target host does not have. Some
virtual machine (vmware or alike) are fine for that I think.

For source packages supporting several platforms and
configurations `reliable' IMHO is not possible, because for
testing (before each release containing any change) you would
need to have all combinations of environments. When you have five
combinable features for five platforms, you'd need at least five
virtual machines (if the features are --enables that are possible
always) preforming 160 builds in total.

(I hope I didn't missed the topic?)

oki,

Steffen