[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    That admin/libtool update
From:       Michael Matz <matz () kde ! org>
Date:       2002-03-10 10:18:07
[Download RAW message or body]

Hi all,

If answering bear in mind, I don't read kde-devel@, so either include me
directly, or use kde-core-devel@.

short version:
* get autoconf 2.52, automake 1.5 if you don't have them already
* rm -rf $buildir (1)
* make -f Makefile.cvs
* (cd $builddir; $srcdir/configure $kdeconfoptions; make; make install)
alternative to (1) without guarantees:
* rm $builddir/config.cache
* find $builddir -name '*.la' | xargs rm
* find $builddir -type f -perm 755 | xargs rm

long version:
the last days there was some heat on the lists about the recent libtool
update.  My mail to kde-core and kde-solaris/nonunix obviously wasn't
enough, and I can understand people seeing it like this.  I should have
mentioned, that it requires autoconf 2.5x.  That it will need relinking
everything is something which I considered immediately clear, but
obviously I was wrong in that respect.

I'm sorry I didn't send out a mail explaining it in excruciating detail
when I commited it, but at that time I could barely walk straight, not
because of the amount of alcohol I usually need before working on libtool
(read my poem regarding that on a former update of libtool on kde-cvs@),
but because of not sleeping for 36 hours or so, after an active week.
That's the reason I also wasn't available yesterday, so I couldn't react
sooner.

Anyway we (I) had good reasons to not only update libtool, but also put it
into the release candidate.  Please do not think we made this decision
lightly. The libtool we were using was based on a discontinued version of
libtool, which never has seen a release.  Not only that, it also was
heavily changed for KDE.  This became more and more of a burden.  One
reason is, that we couldn't incorporate easily changes from the libtool
maintainers (because they are working on a completely different code
base), another reason is that we were getting bugreports, which couldn't
be easily forwarded to the libtool guys.  The reason for really really
wanting it in the release candidate should be obvious: more testing.  As
it also changes some bits in the built libraries we don't want such an
update in some minor version, so KDE 4 would be the next opportunity.
Until then it probably would've broke apart.  So the time was pressing.
Eventual build bugs can be fixed the next week, even without needing a new
release candidate (that's currently only my opinion, but I think Dirk will
agree).

Now to the technical side.  The current system is known to work with
autoconf 2.52 and automake 1.5 on linux.  For automake 1.4 I installed a
hack, so that seems to work too.  automake 2.53 gives strange warnings
which are not caused by us, at least that's my current belief.  automake
1.6 isn't tested by me (was just released some days ago), but reported to
have issues.  Those things I will investigate.  Some months ago I
considered to "port" the then current libtool back to autoconf 2.13, but
never really did the work, partly because it's not really usefull, as 2.5x
is widely available, but see below.

For rebuilding: either start completely from scratch, or remove (in the
builddir) all .la files and all executables.  Remove config.cache, Make
Makefile.cvs, reconfigure, rebuild.  Done.  There was a small time window
where kdesupport was broken, just at the time libtool was updated.  If you
get strange warnings about libxml.la or libxslt.la, update kdesupport and
rebuild.

autoconf/automake are development tools.  They are not needed for those
downloading tarballs/snapshots or release candidates.  I.e. they are
needed only for developers.  I expected developers to be able to update
two stinky packages on their own.  There are other projects which have
much stricter prerequisits, than just some version of autoconf/make
released a long time ago.  Sorry, but I can't resist to say: If you fear
about "updating you operating system"  (although I find it strange that
someone believes to have to update a system for a package), then for gods
sake, just install that tool into /usr/local, which is even how it
installs itself by default.  Or to be really really sure, into
$HOME/install.  That way it can't disrupt anything.

That being said yesterday coolo installed a hack for all who didn't want
to update auto*.  Please be aware, that this will not last for long, and
bugreports against admin/old-* will be forwarded to /dev/null.  Please use
more current auto*, and try to find build bugs with them, which exist, I'm
sure.  Even more so, on archs != linux, as the new libtool is a little bit
stricter.


Ciao,
Michael.
P.S: That with the alcohol was a joke, for those of you permanently stern.

[prev in list] [next in list] [prev in thread] [next in thread]