bug-readline
[Top][All Lists]
Advanced

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

Re: [Bug-readline] making shared link failures fatal


From: Mike Frysinger
Subject: Re: [Bug-readline] making shared link failures fatal
Date: Sun, 27 Mar 2011 01:17:48 -0400

On Sat, Mar 26, 2011 at 2:43 PM, Chet Ramey wrote:
> On 3/26/11 2:03 PM, Mike Frysinger wrote:
>> On Sat, Mar 26, 2011 at 1:47 PM, Chet Ramey wrote:
>>> On 3/25/11 2:55 PM, Mike Frysinger wrote:
>>>> or even better, why not just convert to libtool already ?  every other
>>>> major project out there has long ago switched to libtool.  that would
>>>> detect whether the target supports shared libraries at configure time
>>>> and disable it by default.
>>>
>>> I'd advise you to take a look at it before shooting from the hip next
>>> time.  The readline build system has always detected supported and
>>> unsupported systems at configure time.  It's reasonable to have a
>>> discussion about this, but don't pull bogus arguments out of your ass
>>> to do it.
>>
>> i dont see any arguments pulled from my ass here, so i dont know what
>> you're referring to.
>
> Really?  The only reason you supplied above was that libtool detects
> whether or not shared libraries are supported at configure time.  The
> existing system already does that, so it's a wash and not a compelling
> argument to switch. If that were the only reason, it would actually be
> an argument against spending the time and effort.  Since you presumably
> wrote that because you didn't check whether or not the existing scripts
> do it -- you would not have had you looked -- it's an argument you pulled
> out because you thought it was true.

the way you phrased things ("shared library creation and installation
is enabled by default") made it sound like there was no such
detection.  thus i suggested an alternative (libtool) which already
had all of the desired features packed & baked.

so no, i wouldnt phrase it "pulling it out of my ass".

>> libtool has obvious advantages -- you no longer
>> have to maintain your own hand coded list of targets/flags/etc... for
>> how to build up shared code.  what reason is there nowadays for doing
>> so other than "we already know what we have today" ?  i dont see any
>> downsides to the conversion other than time to implement.
>
> You're correct -- it's mostly inertia, that the current system does
> the job, and the fact that readline and bash can share that code.  The
> current scripts are also much smaller, much simpler, and overall much
> more lightweight than any libtool solution.  My impression of libtool
> was a huge, complex, and fragile system that I simply didn't want to
> incorporate -- my time was better spent on other things.

personally, i havent seen issues with it, and ive used it to do some
crazy shit.  the only time "fragile" really enters the equation is
when doing multiple subdirs each building up their own sublib which
ultimately get linked together.  since readline doesnt do that (all of
the sources are in a single directory), i dont think it would be that
big of a deal.

obviously familiarity with the build tools goes quite a long way, and
what you have now you presumably know.  maybe i'll hold off on the
automake/libtool suggestions until another maintainer takes over who
isnt familiar with your tree.
-mike



reply via email to

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