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

[Charles Wilson]

Alexandre Duret-Lutz wrote:

> > > > "Charles" == Charles Wilson <address@hidden> writes:
>
> [...]  
>  Charles> You have to use Charles> 'lib_LTLIBRARIES" instead
> [...]
>  Charles> With that change(*), then this test fails without
>  Charles> your-version-of-my-patch to progs.am, and passes with
>  Charles> that patch to progs.am.
>
> Thanks, I'm checking in the appended patch.


Cool  -- that looks good to me.

> In my opinion this is a double Libtool bug:
>
>   1. it doesn't delete a.exe in addition to a.out
>   2. it run some C++ test although we don't use C++.
>
> The last time I checked Libtool CVS, it would systematically run
> tests for all languages it knows (C++, Java...) even when not
> used.  So I assumed that CVS HEAD was not ready for public use.


Well, it boils down to philosophy: is "libtool" (the script that is 
generated during configure) a tool that should be

  1) configured specifically for the capabilities of the platform on 
which it will run (set A), without regard to the needs of the package in 
which it is being used (set B)?

  2) configured specifically for the package in which it is being used 
(set B), without regards to the capabilities of the platform  (set A) on 
which it will run?

  3) configured to support the minimum intersection of the needs of the 
package (set B) and the capabilities of the platform (set A).

Note that if set B is not fully contained within set A, you'll get a 
runtime error, in all three cases.

Current libtool behavior is #1.  You are advocating #3.  #2 is 
nonsensical, of course -- if the package needs g++, but I don't have 
g++, I certainly shouldn't build a libtool that blithely calls g++...

IMO, to implement #3 means a lot of work -- you must analyze all of the 
Makefile.am's to see if there are any cxx files (but what if you use 
libtool + autoconf, but not automake?  what if you use libtool 
standalone?).  Or, you impose the requirement on configure.in writers 
that they must specify what they need libtool for:

AC_LIBTOOL_WITH_CC
AC_LIBTOOL_WITH_GCJ
AC_LIBTOOL_WITH_CXX
AC_LIBTOOL_WITH_RC

etc.  That's pretty ugly.  It seems that the libtool folks have decided 
to follow choice #1 -- make a fully capable libtool utilizing everything 
the platform allows.  Then, let the package use that libtool script as 
it wants.

So, I don't think that's a bug -- just a design decision.  OTOH, not 
removing a.exe is a bug, and I've posted a patch on the libtool list. 
'Course, nobody with checkin privs seems to be reading that list...

--Chuck