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

[Charles Wilson]

Tom Tromey wrote:

> > > > > > "Charles" == Charles Wilson <address@hidden> writes:
>
> Robert> What you need to patch is libtool - see mode=clean.
>
> Charles> Perhaps -- but that STILL would require automake to be
> Charles> patched.
>
> Yes.  If `libtool --mode=clean' is the best thing to do moving
> forward, then let's change automake to use that.


That's easy enough, and I could generate a new patch to do that pretty 
easily.  However, IMO libtool --mode=clean is thoroughly broken on 
cygwin, and may not even work correctly on other platforms, when used to 
remove executables (e.g. putting it into **progs.am** at this time would 
be a step backward, not forward).


> Charles> However, I DID think about doing that ^^^.  Unfortunately,
> Charles> libtool --mode=clean doesn't work with executables and
> Charles> wrapper scripts and the .libs/ subdirectory; although it may
> Charles> work okay when cleaning up libraries.
>
> Robert, how hard is it to fix this in libtool?


IMO hard as hell.  But since I won't be doing the coding, it's NMP. 
I've used up all the time I have for the autotools for the next month 
(at least).


> Charles> Since automake hasn't made any previous gestures in the
> Charles> direction of 'libtool --mode=clean', I figured why start
> Charles> now...this patch to automake WORKS, allows users to do a
> Charles> "make clean" (dist-clean, etc) and actually get a CLEAN
> Charles> directory.

> I'm not overly fond of that patch.


Yeah, it's pretty ugly.  But it has the virtue of working.

Problems with the patch

1) hardcodes a specific set of subdirectories ".libs/" and "_libs". 
This is bad.  What if somebody had a non-libtool-related subdirectory 
named _libs (on unix, where libtool uses .libs) or .libs (on DOS, where 
libtool uses _libs).  You might delete something important.

A) yes, but clean-libtool: rule already blindly rm -rf's the .libs and 
_libs subdirectories, so we can be pretty sure that autotooled projects 
that use libtool (the only kind my patch would affect) are NOT using 
.libs/_libs for some other purpose.

2) The presence of 'foo' in *_PROGRAMS could lead to six different files 
being deleted.  That's counter-intuitive.  Are you sure that all of 
those six files are REALLY generated by libtool?  What if they are NOT 
libtool-generated?

A) Sure, that's a possibility.  But not very likely.  Unix platforms are 
not going to use ".exe" on anything.  If a libtoolized cygwin/dos 
project has an executable/script that is the same name as a target 
executable in the SAME directory, but without the .exe ending -- it's 
either libtool-generated, or will be clobbered by the libtool wrapper 
script the next time you run 'make'.  And, the .libs/* & _libs 
subdirectories -- I covered that in #1.

3) It's ugly. 'libtool --mode=clean' is much better.

A) Sure, but this works *now*.  We can change to 'libtool --mode=clean' 
once libtool is fixed.

4) It's slow. 'rm -f $(LIST OF FILES)' is much faster.

A) Yes, but you only incur this penalty for libtoolized packages.  And 
even if 'libtool --mode-clean' worked, THAT would have to loop through 
the names one at a time (inside the libtool script).  So the price of 
correctness is a loss of speed, regardless.

All that having been said, I'll probably keep the patch in the cygwin 
"fork" of automake until 'libtool --mode-clean' works, and then revert 
cygwin-automake back to mainline...

--Chuck