Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]
- From: "Daniel Macks" <dmacks netspace org>
- To: "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, 04 Aug 2010 14:57:55 -0400
On Wed, 04 Aug 2010 19:29:23 0200, Ryan Lortie wrote:
hi Kevin,
>
> On Wed, 2010-08-04 at 08:39 -0700, Kevin Fox wrote:
> > On Tue, 2010-08-03 at 18:42 -0700, Ryan Lortie wrote:
> > > I am experimenting with living a libtool-free
> > > existence.
> >
> > Out of curiosity, why?
>
> Short version:
>
> 1) I don't believe that I need it.
>
> 2) It has many features that are actively causing me pain.
>
>
> Expanding on each of those points:
>
> First, dconf is only really intended to be used on free operating
> systems. It will never be used on Windows and probably not on Mac OS
> either. That greatly reduces the complexity associated with building
> shared libraries.
[...]
My intention is to develop a small m4 macro that guesses the correct way
> to build shared libraries on a small selection of common Unix flavours,
> at configure time, and use that instead. Quite some people have
> indicated to me that they would be interested in using this macro after
> it becomes clear that it properly handles such a range of systems.
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.
dan
--
Daniel Macks
dmacks netspace org
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]