Re: PACKAGE_NAME, PACKAGE_VERSION etc

[Bob Friesenhahn]

On Wed, 18 Feb 2004, Daniel Reed wrote:

> On 2004-02-18T10:15-0600, Bob Friesenhahn wrote:
> ) On Wed, 18 Feb 2004, Daniel Reed wrote:
> ) > If at all possible, simply do not include both config.h files in your 
> code.
> ) > If you need the output from one autoconf check in both config.h files,
> ) > simply repeat the check in both project's configure.ac files.
> ) This is not very efficient and doesn't make much sense at all.  If the
>
> I tend to disagree, given the availability of -C. It is my general stance
> that packages should not be checking for things they, themselves, do not use
> (even if their subordinate packages may). Let the master package check for
> things it needs, let its subordinates check for things they need, and if

You are assuming that all libraries are subordinate in a build.  I
don't see any reason to assume that.  A library can be delivered by a
3rd party or otherwise built independently.

> there is overlap, rely on autoconf to do The Right Thing(TM). This is how
> libltdl works, and this is how I have constructed my own sub-packages to
> work.

Correction: that is how libltdl used to work.  For libtool 1.6 it will
work quite differently (no subordinate configure script).  The reason
for the change is that the extra configure script bloats packages, and
takes a long time to run.

> ) library configuration uses user supplied configuration options then
> ) there may be a mis-match and bad things will happen.  It doesn't make
> ) sense for an image library's configuration script to test to see if
> ) X11 supports the shape extension because it relies on some other
> ) library to handle X11.
>
> I am not personally convinced that recording installed-software availability
> information (and subsequent feature capabilities) in header files is the
> right thing to do.

It is necessary in order to compile the library which directly uses
the feature.  There is normally no need for other libraries to know
about the features.

> Consider: If I install libfoo and it requires libbar to support .bar files,
> what happens if I later install libbar? I must recompile libfoo. If I
> installed foomaster in the meantime, and it relied on libfoo.h claiming that
> .bar files were not supported, foomaster would need to be recompiled as well
> (after recompiling libfoo, after installing libbar).

Exactly.  That is why the argument that dependent libraries should
have their configure scripts replicate the configure tests required by
the libraries they depend on doesn't make sense.

> ) Library headers are often dependent on the library's "config.h".  The
>
> And just to reiterate, I consider that to be poor practice. Auto-generated
> config.h files should rarely, if ever, escape the build tree.

I have heard that argument before, but there can be good reasons to
install a configured header.  Taking my package as an example, its
library may be configured to use 'unsigned char', 'unsigned short', or
'unsigned int' as its basic storage element. It is necessary to supply
a configuration define as part of the installation process since the
API interface headers need to know the size that the library is built
to use.  If a dependent application gets the size wrong, then Bad
Things Happen (TM).

Rather than say that it is wrong for a library to install a
configuration header, perhaps it would be better to say that it is
poor form for a library to install a configuration header which
includes defines that are not necessary in order to define the library
interface.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen