On 2009-10-25 Robert Hogan <rob...@roberthogan.net> wrote: > On Sunday 25 October 2009 14:18:07 Andreas Metzler wrote: >> I think this is caused by mixing old ltmain.sh in ./admin with new >> libtool.m4 in /usr/share/ or something like that.
> Interesting, I tried libtoolize to no avail - it just broke the build even > further. > I checked the admin folder in the kde-common module in the KDE 3.5 SVN repo > and it as old as mine. > Any ideas on what to do/try out to remedy this? (Other than hand-edit the > admin folder!) [...] Hello, I am neither an auto* guru nor familiar with this style of autotools handling, so please take the rest of this mail with *huge* grain of salt. Afaict it basically works like this: The jobs usually done by aclocal and libtoolize are done centrally in SVN. Somebody keeps the copies of the respective tests and scripts in admin/ up to date and Makefile.cvs or whatever imports them into the project. The stuff (m4 tests) in admin/ is complemented by the stuff available in the system (tests included in the autotools suite). This can fall apart if admin/ is not kept up to date. Some of the stuff in admin might require updates to work with newer autootools files on the local system. Afaiui autotools code in KDE (admin/) *is* dead and unmaintained. KDE has switched to cmake. For tork this probably leaves: * Follow KDE and switch to cmake. * Use normal autotools handling. I am not sure this is workable, since the m4-tests for KDE are not maintained upstream. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
