libtool
[Top][All Lists]
Advanced

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

Re: .exe magic


From: Charles Wilson
Subject: Re: .exe magic
Date: Wed, 18 Apr 2007 14:49:31 -0400
User-agent: Thunderbird 1.5.0.10 (Windows/20070221)

[added libtool to CC list]

Corinna Vinschen wrote:
On Apr 18 04:49, Charles Wilson wrote:
The current .exe behavior has benefited from many years of tweaking and fine-tuning, across many different packages (cygwin, gcc, gdb, binutils, automake, autoconf, libtool, bash, coreutils, ...) to work together to give the current, mostly coherent, least-surprise behavior we enjoy today. [...]

Apart from that, I don't like what libtool does.  I think it's a
terrible idea to have a script and a binary with the same name (only
differing by the .exe suffix) in the same directory.  This behaviour
breaks the CYGWIN=transparent_exe option and there's no reliable way
around this.

Is there any chance that this could be changed in libtool?

Absolutely.  I outlined the steps necessary to do this:
http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html

But got not P to TC.  Any takers this time around?

Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so the desired fixes will have to wait until after 2.0 (or 2.2, or whatever the heck we decide to call it) is released. Of the three steps outlined in the "fix", it's possible that (1) and (2) could go in prior to the 2.0/2.2 release, but this kind of thinking is why we're still in slush and haven't released.

--
Chuck

P.S. This will make you cry: libtool-1.5.0 was released 14-Apr-2003, four years ago last Saturday. After a year and a half, some destabilizing changes were under consideration and rejected for 2.0 -- we were "too close to a release" -- so an abortive "branch-2-0" was created 3-Oct-2004 and the "destabilizing" changes went into HEAD. Development continued sporadically on this branch for about a year until 24-Aug-2005 -- but throughout, most development effort remained on the trunk or branch-1-5. The load on the developers maintaining three branches was extreme, and branch-2-0 -- supposedly the "almost ready to release" branch -- was getting short shrift, for a YEAR. And the "destabilized" HEAD was now actually *more* stable than branch-2-0! It got so bad that the branch was abandoned, and 2.0 was retargeted to come from cvs HEAD Real Soon Now. Another year and a half, and here we are...still in code slush.

(Sounds very very similar to the ongoing discussions with regards to gcc-4.2: http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html and http://gcc.gnu.org/ml/gcc/2007-04/msg00510.html. Only much much worse.)

However, there are indications that this situation will come to an end Real Soon Now And This Time We Mean It. So, here's hoping...




reply via email to

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