autoconf trouble

[Enrico Weigelt]

* Daniel Stone <daniel at fooishbar.org> wrote:

<snip>
> > No. I just have to prepend $(SYSROOT) to all appropriate pathes
> > (ie. -L, -I, .la, ...). The right places are easy to find, if 
> > the makefile, or probably it's source is human readable.
> 
> Yes, and there are about ten thousand of them.  But I digress.

Aehm, dumb question: why ?
You're familar with the concept of variables ?

Of course, autoconf spitout has thousands of those points, and
it seems that autoconf folks have missed some fundamental lessons
about code abstraction by functions, modules, etc. But I woulnd't
consider autoconf spitout as human readable either (I had to fix
many "configure" scripts, and it always was a hell ...)

> > > We maintained our own build system with Imake.  And that sucked.  
> > What's wrong with it ? 
> > I hat never problems with it. But I have big problems w/ autoconf
> > almost every day.
> 
> Try running it on a platform other than Linux/i386, then.  We were our
> own porters.

Yes, as it was in the past. Obviously it worked too.

<snip>
> You're speaking to someone who's been maintaining X for two
> distributions, for four years.  autotools is a vast improvement over
> imake from my point of view as both a developer and a maintainer.

I have to maintain a big bunch of distributions. (well I'm not sure
if I really should call it distros - in fact most of the more than
hundred systems are very individual. Varying from embedded systems
to server farms ...). 
To be able to ensure code quality, cross-compiling with sysroot is 
an fundamental concept for me. If some package cannot be built so, 
its simply unusable. Autoconf helps making packages unsable this way.

What's exactly is wrong with imake ?


Well, of course it doesn't go far enough. It's still rule based.
The optimal model for such buildfiles should be some lightweight
and strictly descriptive, which only contains exactly the required
information - and, of course, completely platform / toolchain 
independent. 

For example the build information for libXcmcp could be something like:
(here in some XML presentation - but that's syntactic sugar)


<library name="Xdmcp" include-prefix="./include/"
    <description>
	X Display Manager Control Protocol Library
    </description>
    <include name="X11/Xdmcp.h" />
    <include name="X11/Xdmcpconf.h" />
    <source name="AA8.c" lang="c"/>
    <source name="A8Eq.c" lang="c" />
    ...
</library>


That's all what's individial for libXdmcp. Evrything else is strictly 
derived from that and implemented by an universal library build tool: 

+ pathes (include, libpath, etc)
+ compiling the sources to objects
+ linking the objects to shared / static library
+ generating .pc file
+ installing all files into appropriate locations
+ ...

If someone has some "exotic whishes" to the build system (like me ;-P)
he only touches the common build system - not the packages. And if
some wants to port the build process to some new platform, he also
just touches the buildsystem, not the package. 

There are only a few points where the package is interested in platform 
dependent stuff, ie. endianess, type sizes, etc. For that we simply 
define some standardized symbols - this is also done by the buildsystem.

Of course this only really makes sense, if some more packages use it.
Well, once its running, porting packages away from autoconf, would be
mostly trivial.

<snip>
> > Long long time ago, I've made several proposals for really strict
> > and deterministic buildsystem. If some more folks had have been
> > listening to me, we already could have it working for month and
> > an package's individual build stuff wouldn't be more than a simple
> > text file of about 1k ...
> 
> Proposals are uninteresting.
> 
> If we'd spent all this time writing our own build system from scratch

I've made my proposals long time before the xorg-mod project started. 
If just a few people had joined me these days, we would have been 
ready right now when xorg-mod started.

> (which is non-trivially difficult -- just ask KDE), we'd be even further
Hah. KDE + Qt are excellent examples for design failures you can
make if you're under "bussiness presure". I'm not talking about the
signal-slot-concept - this is great (oberon had this for decades).
And I'm trying not to talk about the missing garbage collection.

But I'm talking about a really bad library structure. Its a big-fat
blob without any clear internal structure. I'm a little bit irritated
by the fact that they praise Qt for embedded systems. Those targets
seldomly have enough space for the library at all.
While I probably could live with the blobness, I definitely cannot live
the fact that using "primitive" types (ie QList) requires an X display
attached, although you're application never ever has any visual object.

Aehm, and if you're thinking about Qmake ... better go out, take 
some fresh air and drop these thoughs asap ...



cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service
  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
---------------------------------------------------------------------
  Realtime Forex/Stock Exchange trading powered by postgresSQL :))
                                            http://www.fxignal.net/
---------------------------------------------------------------------