CMake!

[Dan Nicholson]

On Fri, Oct 10, 2008 at 3:39 PM, Kevin Kofler <kevin.kofler at chello.at> wrote:
>
> * Libtool generates .la files even on platforms which don't need them. It's
> ridiculous that we still have to delete unwanted files in almost all packages,
> and even more so that they have a comment on the top saying "DON'T DELETE THIS
> FILE!".
> (That said, CMake has a similar dependency tracking feature which, when
> enabled, is similarly broken by default. A package has to either not use
> dependency tracking at all (which may cause problems on some
> platforms/configurations, e.g. static libraries) or use an extra command to do
> the right thing (only linking in indirect deps explicitly if the platform
> requires it). But at least it's possible, unlike libtool where you have to
> manually delete a file which screams not to be deleted.)

The reason why the .la file is forced to be installed is because it's
needed to support `make uninstall'. Last I saw, the libtool developers
were considering allowing you to opt out of that situation. It's
certainly come up before, and there should be a way to avoid this.

> - checking that the Fortran and Java-to-native-code compilers exist (even in an
> all-C/C++ project).

libtool-2.2 doesn't do that anymore.

> * Libtool thinks /usr/lib64 needs an RPATH, unless you use a Fedora-patched
> version, in which case it'll think /usr/lib needs an RPATH on x86_64 even on a
> Debian system. So, unless you're about to hack the generated/copied libtool
> scripts manually, there's no way (using libtool) to make a package which will
> generate no bogus RPATHs on x86_64 on at least one distro.

Are you sure about that? Last time I looked (and I did look, because I
was trying to emulate libtool's rpath functionality for mesa), libtool
asks gcc for the system library directories by looking at `gcc
-print-search-dirs'. In libtool-2.2, it also takes into consideration
`gcc -print-multi-os-directory'.

--
Dan