On Fri, Feb 21, 2003 at 10:46:36PM +0200, Tuomo Valkonen wrote:
> On Fri, Feb 21, 2003 at 09:17:14PM +0100, Per Olofsson wrote:
> > Still, some packages may need to check for many things.
> 
> And many of those are standard checks that should be cached and shared
> by programs. But no... Well, maybe it is possible but should then be
> enabled by default.

This is exactly what Imake does. The problem is, according to the
autoconf manual, that the database has to be centralized and it is
very hard to maintain such a database.

> > Yes, but Ion and PWM mostly uses X libraries, which looks mostly the
> > same across all platforms.
> 
> With the compatibility library and standard paths and such given, library
> versions and compile options for them should be the only thing left most
> well-written programs should depend on. There's then no need to lock the
> build process behind an unreliable checking script. 

Don't underestimate the amount of data that packages need to check
for. For example:

* Building shared libraries in a portable way. Autoconf + libtool
  helps much when doing that.
* Checking endianness.
* Checking length of types.
* Headers have different names on different platforms.
  (this one may be quite large)
* Compilers behave much differently.
* libc is full of functions. A library covering all of them will not
  necessary be minimal. (also large)
* Which libraries to use? Which are available, which does the user
  want to link with?

And yes, if there was a library and there was information available,
there's no need to check for all those things. The problem is that
such a library and such information isn't available. I think the main
problem is social--it's hard to make such an infrastructure generally
available and developers don't trust it. Autoconf scripts are, on the
other hand, completely stand-alone.

But that was the situation when Autoconf arrived. Nowadays it's a bit
different. There are many "standard" packages that almost everyone has
so adding another wouldn't be much of a problem. Something I find
quite strange is that many software packages for desktop environments
like Gnome and KDE check for things that the libraries they depend on
already has checked. Why can't they just reuse the data that the core
libraries has already collected? They all depend on these libraries
anyway. I think the situation is worse with KDE--at least glib saves
some data.

So yes, a "minimal" platform library with pre-collected information
may be possible. Technically it is definitely possible, the question
is whether anybody will use it. If it is only used by one package, it
merely complicates things.

Still, I don't see any reasons to blame Autoconf for everything. I
don't think Autoconf is unreliable, I would say it is the input it
gets that is bad then. You should blame the packages that use
Autoconf, not Autoconf itself. If the correct input is given, you can
make it check for exactly what you want. You can even call it from a
makefile rule.

> > I don't think an autoconf script for Ion would be bloated if it is
> > written correctly. You don't have to test for a hundred things, only
> > what you specify in configure.ac is tested for. 
> 
> I have had too much bad experiences with autoconf to trust it enough to
> make it only possible to build Ion by running ./configure. There can be an
> option to automatically create a system.mk, maybe config.h, but it must
> still be possible to build Ion at least as easily as now without resorting
> to autoconf.
> 

First I thought: Let's just add a system.mk.in and let configure
overwrite system.mk if it's used. But that's bad, scripts in a package
should not change the included files. So I think a better solution
would be to name it system-ac.mk.in or something like that, and let
configure generate system-ac.mk. Then the makefile could check whether
system-ac.mk exists, and if it does, use that one, and otherwise just
use system.mk. Thus, if configure is invoked, the data it collects
will be used, otherwise the normal system.mk is used. configure should
probably print a notice about this so that people won't mix things up.

/Pelle

Reply via email to