Re: Automake,cygwin: 'make clean' with libtool wrappers...

[Charles Wilson]

Robert Collins wrote:

> > Let me get this straight: are you advocating that automake 
> > deliberately 
> > break 'make clean' for libtoolized packages on all platforms, when it 
> > was previously working on most platforms -- just to force 
> > libtool to fix 
> > a feature that has been under-used/non-used in the past?
>
> For HEAD, not for 1.6.1. That's what HEAD is for, to make changes to.
> libtool recently broke HEAD when it merged the mlb branch in. They did a
> release immediately before that to give users the latest code.


"recently"?  1.4.2 was released in September, 2001.  There hasn't been 
an official release since then.  (But I take your point -- they branched 
1.4, then merged the mlb branch into HEAD, so head was broken for a 
while.  But, bugfixes could continue to be released on the 1.4.x branch 
regardless).

However, does *automake* use branches?  That is, will AM-1.6.2 come from 
HEAD, or from a 1.6 branch?  If automake-HEAD implements a change that 
causes 'make clean' to fail, but will not/can not be "fixed" until 
libtool releases a "compatible" version which has the 'working' 
--mode=clean, then can 1.6.2 EVER be released (in a working state) until 
after libtool+working_mode=clean is released?

> so libtool '--mode-clean foo' should assume that foo is a program. Ok.


No, of course not.  But doesn't libtool test the file to determine what 
it is?  If you give it a 'foo' (a wrapper), or foo.exe (an executable), 
then I *thought* there was code in there to figure that out and then 
only delete that (and not 'libfoo.la' or './libs/cygfoo-3.dll'...). 
It's just that the "how do I delete an executable" code is broken on 
cygwin (and maybe other platforms).  As I said in my first message, the 
"how do I delete a library" code inside libtool _seems_ to be working ok.

Once mode=clean knows that (a) it was given an executable (or wrapper) 
to delete, and (b) it's running on cygwin/windows/dos/whatever -- then 
libtool ought to know enough to delete ./foo.exe (if foo was built 
statically) or .libs/foo.exe and ./foo (if foo was built dynamically).

E.g. I think the first paragraph above is already there, but the next 
paragraph isn't.  But with all the code duplication, doubly- and triply- 
evaluated shell variables, sed,this,, and sed,,the other, I couldn't be 
sure.  And was running out of time.

BTW, I even ginned up a "fixup_libtool" script that automatically and 
liberally sprinkles "echo <lineno> ;" throughout libtool just to TRY to 
trace its operation...it was quite helpful to me in fixing other areas
if not this one.  I could send that to you if you thought it might help you.

--Chuck