From kde-core-devel  Wed Jun 15 12:13:03 2005
From: Hans Meine <hans_meine () gmx ! net>
Date: Wed, 15 Jun 2005 12:13:03 +0000
To: kde-core-devel
Subject: Re: Build system for KDE4
Message-Id: <200506151413.03504.hans_meine () gmx ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111883759520994

Hi Stefan!

On Tuesday 14 June 2005 14:03, Stefan Teleman wrote:
> first, we have a generically vague statement "automake sucks". i have
> several of these too: Python sucks, C++ template function pointer
> syntax sucks. are they useful ?
FWIW, I don't think "automake sucks".  I believe the *concept* of automake, 
autoconf, and libtool is great.  Still, practice has really made me hate this 
toolchain.

Some ugly facts that have been mentioned here:

- On the positive side, there is a theoretically very high portability of the 
resulting configure file.  However, this results in configure scripts that 
are
  * incredibly and ridiculously large (e.g. 1.603.833 bytes)
  * take incredibly and ridiculously long to run (timed 10 Minutes on our 
SunOS server, *with* fast-perl!)
- Furthermore, the availability of "good", standard configure checks is low, 
and hardly anybody is able to write them, since it requires
  * knowledge of M4 (easy, but ugly) and M4 and autoconf macros (hard part) 
which are quite obscure and change between versions and so on (compare this 
with python, which is easy to learn and offers nice, intuitive string and 
list objects with nice convenient methods)
  * knowledge on the availability and compatibility of sh/sed/grep-constructs, 
parameters and variants (this is where the theoretical portability of 
configure scripts gets lost in practice)
- The advantage that end-users do not have to have automake/autoconf installed 
is narrowed by the disadvantage that developers have to have dozens of 
different autoconf/automake versions installed, because they differ so much 
and are not backwards-compatible and each project uses a different version 
(apart from that, the availability of python is very high nowadays)
- I find it hard to strip configure files down to what I really need, and 
trying to make distributions, I often end up with configure files that try 
running automake or autoconf again on end-user machines (and then fail 
because of a wrong version).

Finally, 99% of my problems getting KDE to run here at our university can be 
attributed to the build system.  See e.g. the config.pl fix that I sent 
today, and right now I had to hand-edit arts/mcopidl/mcopidl, the libtool- 
generated wrapper script, because it tried to do

LD_LIBRARY_PATH="$thisdir/../mcop/.libs:/software/glib-2.4.7/SunOS-5.8/lib:/software/gettext-0.11.5/SunOS-5.8/lib:/software/libiconv-1.8/SunOS-5.8/lib:" 
exec $progdir/$program ${1+"$@"}

which means that the LD_LIBRARY_PATH which it carefully set up only seven 
lines above (line 80 here) gets overwritten and I get
ld.so.1: /raid0/sw/kde-3.4svn/source/build-SunOS-5.8/arts/mcopidl/.libs/mcopidl: 
fatal: libstdc++.so.2.10.0: open failed: No such file or directory
Killed
because C++ runtime library is missing from LD_LIBRARY_PATH.

This is a typical case of libtool's unnecessary and harmful 
trying-to-be-too-intelligent which I always thought to be M$-behaviour.

Although I don't know scons/bksys yet, I am hoping that something like that 
will be tomorrow's build system.

Ciao, /  /
     /--/
    /  / ANS