Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]
- From: Havoc Pennington <hp pobox com>
- To: Daniel Macks <dmacks netspace org>
- Cc: "gtk-devel-list gnome org" <gtk-devel-list gnome org>
- Subject: Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]
- Date: Wed, 4 Aug 2010 16:33:38 -0400
Hi,
On Wed, Aug 4, 2010 at 2:57 PM, Daniel Macks <dmacks netspace org> wrote:
> Well, it's fine if you don't intend to test it on those systems, but others
> certainly are. For example, I manage the gnome suite for Fink, where our
> users can run a fullish gnome desktop environment (I think similar package
> suites are available in MacPorts as well). If dconf is trying to be a part
> of the gnome desktop, I don't think setting up intentional roadblocks to
> portability is a good idea--i.e., it sounds like you're headed towards
> hardcoded potentially non-portable methods.
> Seems like every time someone tries to reinvent a simpler system, they
> either wind up with a buggy mess or something at least as complicated and/or
> less portable than libtool (or at least automake). There are already lots of
> build-system alternatives (I think KDE recently switched to cmake, which
> took years just to be able to build shared libraries properly on OS X).
> You're the developer, it's your time to spend as you please obviously, but
> seems like there are better things to be doing than reinventing some
> already-tested wheels.
automake is fine, but libtool is a real problem. It seriously
lengthens compile/install times in a way that's probably wasted tens
of thousands of developer hours over the years, *at least*. In all
honesty, most likely any of us who write a lot of C code could get
back the time spent patching libtool out of automake *just in time
saved personally*, let alone time saved for everyone else.
I have a personal project where I'm not using convenience libraries
for files that are part of a half-dozen executables because it's
faster to compile files 6 times than it is to use a libtool library.
Not to mention minor aggravations like typing "libtool --mode=execute"
and .la files storing stale dependency info.
Given this I'm not sure why nobody has ever replaced libtool while
keeping automake. For me it's probably 1) automake is written in perl
which I just don't speak and 2) suspicion that automake upstream
wouldn't take the patch. I am completely happy with automake
(especially when used nonrecursively). But libtool is too
anti-productivity to live. If automake could just build a frickin'
shared library instead of .la-hell, it would be a big upgrade.
Or if someone could fix libtool so it isn't slow, and doesn't create
annoying .la files on platforms that don't require them, that would be
great too.
In short, go Ryan!
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]