Re: Maintainer friendly mode for autotools projects

[Bob Proulx]

Ivan Levashew wrote:
> Autotools are by default in an user friendly mode (I don't know how to  
> name it better).
>
> User friendly mode assumes that an user compiles and installs a software  
> just for himself.

I think I would call that developer mode.  If you are compiling
software then you are more of a developer than a user!  Sometimes
people talk about software builders which are not quite developers but
are simply building the software.  But I acknowledge that this is just
quibbling over names.

> 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.

This has been tried in the past.  Many, many systems prior to the GNU
autotools have required manual configuration by the developer.
However the GNU autotools were developed to as automatically as
possible create the correct local system specific configuration.  It
does this by running tests to determine the local system
configuration.  Many of those manual configuration systems still exist
today too but most projects have replaced those with an autotools
configuration because it works quite well for both builders and
developers.  I see this as a vote that autotools is more useful to
more people than the manually configured ones.  A "natural selection"
which has caused a general replacement of other systems with an
autotools one.

Plus the autotools configuration may also be configured manually.  By
default it will do things as automatically as possible but you may
override this so as to prevent it running any tests.  For example this
is typically needed for cross compile environments.

> It really annoys me that so many accidents can happen! CocoAspell  
> installs its library into /usr/local/lib, and my programs accidentally  
> are being linked against it! I want to be in "cross compile" mode even  
> if it's not the case. That would the best service for me, because my OS  
> can easily happen to be better than end user's one.

Most people want /usr/local to be the location for local system
headers, libraries and configuration.  This is also standardized by
the FHS too.  If you want your system to be different then you would
be the "odd person out" and would need to configure things to be
differently on your system.  Fortunately this is quite easy.  Look at
the AC_PREFIX_DEFAULT variable as one way to change the default
installation location.

> 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?

You can control this by setting variables that pre-answer autoconf
tests and override the default result.

> I'd like ./configure to retrieve values from a knowledge base.

You probably want to set up a local config.site file and in it set all
of the configuration that you desire.  This is documented in the "Site
Defaults" section of the Autoconf documentation.

  info -f autoconf "Site Defaults"

  Autoconf-generated `configure' scripts allow your site to provide
  default values for some configuration values.  You do this by creating
  site- and system-wide initialization files.
     If the environment variable `CONFIG_SITE' is set, `configure'
  uses its value as the name of a shell script to read.  Otherwise,
  it reads the shell script `PREFIX/share/config.site' if it exists,
  then `PREFIX/etc/config.site' if it exists.

I could quote much good documentation from that section but I think
that pointing you to it will be enough.  Ask more questions if
something in that section isn't answered sufficiently.

> 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. Would you be so kind to point me on where to look for  
> information?

Here is a hint.  If you want to create a non-shared area (e.g. not in
/usr/local) for installing a particular package or group of packages
then setting PATH and overriding prefix is usually enough.  Here is an
example from one of my build environments:

  PATH=/usr/local/build/coreutils/bin:$PATH
  ./configure --prefix=/usr/local/build/coreutils
  make install

Because PATH now searches for the .../coreutils/bin/ path first any
executables there will override any found in /usr/bin/ from the
system.  (This assumes that nothing is hard coding a full path which I
consider bad for a number of reasons.)  Then configure is instructed
to use that as the prefix.  The 'make install' (and associated 'make
uninstall') will install to that location.

Bob