Date: Fri, 5 Mar 1999 06:24:23 -0500 (EST) From: Chuck Robey <chuckr@mat.net> To: Jeremy Lea <reg@shale.csir.co.za> Cc: Satoshi Asami <asami@FreeBSD.ORG>, garyj@muc.de, freebsd-ports@FreeBSD.ORG Subject: Re: all those .la files Message-ID: <Pine.BSF.4.10.9903050615230.326-100000@picnic.mat.net> In-Reply-To: <19990305125643.H85737@shale.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 5 Mar 1999, Jeremy Lea wrote: > Hi, > > On Thu, Mar 04, 1999 at 10:31:23PM -0500, Chuck Robey wrote: > > They're not, most ports have their own captive ltmain.sh to create a > > libtool they have of their own, and will each of every one of them > > require patching to use a coomunity libtool. Why you'd want to go to > > all that work to memorialize a piece of broken software is completely > > beyond me. Libtool serves to solve *no* problems that we have, and > > manages only to add the .la files which we don't want. > > You're not listening... Libtool is here to stay, along with all the > other broken GNU build tools, like autoconf and automake. ltmain.sh and > ltconfig are always taken directly from the libtool distrubtion, they > are not customised. [much elided here] > With fear of Brett reading this... The GNU build tools are not designed > to improve platform portability, but to lock you into a GNU environment. > > The patching to remove libtool use from these ports would be huge, and > the amount of work to get Linux centric projects to stop using libtool, > automake, autoconf and other wastes of time is even more. I mean the > GNU tools must be good because they're all lovingly written by RMS... Here's where we disagree (and I think that's the problem). Yes, you may be right about libtool being here to stay, although since it's the worst of the lot, I wouldn't want to bet any big money on it... the point, tho, is your line: "The patching to remove libtool use from these ports would be huge" In order to get each port to use a common libtool, the exact same amount of patching will be required as would be required to take it out ... no difference. With the same amount of work, we can bring in a very broken tool, or remove it. That's the option. If we take it out, that removes the .la problem at one stroke, it's *real* easy to maintain (we all know how to compile and link on FreeBSD, no trying to read minds required) and we send a message back to the libtool maintainers via all the software developers who *do* see what we do. Jeremy, I better admit here that I like to argue ... if we want to take it any further, why don't we take it offline, come to a decision, and bring it back to the list? Satoshi is going to do the best for FreeBSD irregardless, and we can just report that we have or haven't changed our opinions. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9903050615230.326-100000>