X-Spam-Check-By: sourceware.org
Message-ID: <4626683B.6050609@cwilson.fastmail.fm>
Date: Wed, 18 Apr 2007 14:49:31 -0400
From: Charles Wilson <libtool AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
CC: libtool AT gnu DOT org
Subject: Re: .exe magic
References: <46254976 DOT 4000308 AT cygwin DOT com> <loom DOT 20070418T010849-170 AT post DOT gmane DOT org> <4625DB90 DOT 6000001 AT cwilson DOT fastmail DOT fm> <20070418100925 DOT GJ5799 AT calimero DOT vinschen DOT de>
In-Reply-To: <20070418100925.GJ5799@calimero.vinschen.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

[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...

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/