gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: Managing changes to projects that use autoco nf


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: Managing changes to projects that use autoco nf/automake with tla
Date: Tue, 6 Apr 2004 09:00:27 -0700 (PDT)

    > From: Stig Brautaset <address@hidden>

    > > By the way, having worked a little bit with package-framework, I like 
it.

    > I like it too. I would love for it to get shared library support though.
    > That is the main gripe I have with it and the principal reason people I
    > recommend it to don't bother looking at it. :(

    > Anybody have any idea how hard it would be to add support for shared
    > libs to hackerlab (using libtool) would be, and, Tom, would you be
    > willing to merge it if someone contributed code to do this? 

Well, I'm of three minds on the subject.

On the one hand, I'm dissatisfied with the implementation of
package-framework.  Not the design -- just the implementation.
I can just _feel_ it starting to get unweildy.   To fix it, I want to
get rid of GNU make and sh both -- and that's not a small problem.  I
want to replace them with something small enough to be distributed
with packages.   So, in general terms, extending the current
implementation indefinately is not my favorite idea, although my
favorite alternative is a Big Project.

On the other hand, sure, I'm willing to merge in shared library
support.  I'm not too enthusiastic about the implementation of
libtool.  What I'd really like to see is a project that spends a few
weeks and a couple of "spare evenings" volunteers to _extract_ from
libtool some of the platform-specific knowledge it contains.   I'd
like to see it produce a document and database:  the document
describing the variations on shared lib handling in the natural world
and commenting on what abstractions make sense over those;   the
database capturing the platform-specific knowledge in a handy format.

The upshot of that is that I'd like to see libtool gutted, skinned,
and cooked up into a package-framework extension.

On the third hand, I did try to make it easy to integrate external
tools into package framework.  Using libtool directly is probably the
easiest option.

That the first idea (redo package-framework) is my favorite idea, but
expensive, the third idea (use libtool directly) is probably better
than the second.   I.e.: a low investment in a doomed implementation
that, nevertheless, makes the doomed system wildly more useful.

In summary:  yes.


But now you have a better map,
-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]