Re: [ITP] util-linux

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Peter Ekberg wrote:

> With transparent_exe, I'd argue that $EXEEXT should be "". Fix that first, then
> I think the stupid foo.exe wrapper

It's interesting that you call the foo.exe wrapper "stupid" or "really 
silly"...while highlighting the exact reason it is necessary: make 
rules.  I assume you'd prefer to have "a bunch of undesireable behaviour"?

Sure, if transparent_exe had always existed, then maybe we would have 
coded some other solution back in the day.  But it didn't exist.  Plus, 
mingw doesn't have it, and the libtool code is mostly shared between 
cygwin and mingw -- as is proper, because these are *platform* issues. 
I wouldn't lightly discard backward compatibilitiy nor cavalierly break 
another platform -- not that any change that did so would be accepted by 
the libtool maintainers.

> can be zapped for Cygwin. I haven't really
> digged into the problem though, so surprises might crop up...

That's an understatement.

But what you're proposing is to change libtool (actually autoconf, as 
well as automake) so that they no longer use EXEEXT=.exe on cygwin (and 
in libtool's case, bypass the binary-wrapper generation).

Which is fine as far as it goes -- except that now libtool, and 
autoconf, and automake, and any project that uses these new versions of 
the autotools will be broken (unbuildable on)
  (a) older cygwin
  (b) any cygwin that doesn't use transparent_exe

I'm not even addressing perl's Config.sh, zlib's non-autoconf configure 
script, and a bazillion other projects' hand-coded non-autoconf 
makefiles which currently detect the win32 platform and set EXEEXT (or 
some equivalent).  If they changed to follow Peter's policy 
(EXEEXT=<empty> on cygwin), then they too would be broken on older 
cygwin or without transparent_exe.  But that's their problem I suppose, 
not Peter's.

Peter's idea, in order to be implemented to fix the libtool "problem", 
requires a change to autoconf.  And THAT is gonna ripple in a BIG way -- 
and must be coordinated between the autoconf and libtool teams, and 
neither group is likely to take a change that deliberately breaks all 
backwards compatibility on cygwin.  And I'm not very likely to push for 
them to do it, either.

But, assuming such a change WERE made to autoconf/automake/libtool, in 
effect you've now make transparent_exe NON-optional, for any use of 
cygwin that involves the autotools (and whichever other non-autotooled 
projects follow lemming-like off that cliff).  It would be better in 
that case to make transparent_exe NON-optional and then "fix" 
libtool/autoconf (ie. break them on older cygwin).

No thanks.  (Plus, depending on which version of the autotools a 
third-party-maintainer used when releasing their latest-n-greatest, 
you'd need to set/unset transparent_exe -- older packages need it unset 
because the binary/script wrappers will collide otherwise, but newer 
ones MUST have it set or make will go nuts because the rule is never 
satisfied otherwise.  What a nightmare.)

My position, regardless of whether transparent_exe HIDES the truth from 
the user, is that on any windows platfrom -- 
cygwin/mingw/cmd/whathaveyou -- EXEEXT *is* .exe.  If you set EXEEXT=, 
then you're just lying to yourself (but maybe using transparent_exe to 
get cygwin to go along with it).

For compatibility reasons, I'd like to AVOID having both foo.exe and foo 
in the same dir -- I never liked it in the first place -- but still 
satisfy make's requirements, regardless of what version of cygwin is in 
use or whether CYGWIN contains transparent_exe.  There is a way, but 
EXEEXT= is not it.

----

Neither is this pile of crap:

case $host in
*cygwin* )
if [ `echo "${CYGWIN}" | grep "transparent_exe"` ] ; then
  EXEEXT=
else
  EXEEXT=.exe
fi
*mingw* )
  EXEEXT=.exe
esac

That's just WRONG, and breaks [i.e. is non-portable between 
old-cygwin/no-transparent_exe and new-cygwin/with-transparent_exe] if 
the result is ever persisted in expanded form (in, say, a generated 
makefile).   Also, for libtool, it'll break back-linking (.la files for 
.exe's; too complicated to explain here).

-----

You're trying to solve a problem created by a new *optional* feature of 
cygwin, by deliberately breaking libtool's ability to operate WITHOUT 
that feature -- including on any older cygwin installation.  By 
implication, however, it's worse: because libtool doesn't set EXEEXT 
itself; it relies on autoconf to do that instead.  So you really want to 
change autoconf.  Talk about ripple effects...then ANY project that uses 
autoconf wouldn't build properly unless cygver>1.5.20 and 
CYGWIN=transparent_exe)

Not only no, but HELL no.

I will *not* subject myself to answering the 900,000 emails that say 
"why is libtool/my-favorite-autoconfed-package broken on cygwin" if a 
change like this affecting EXEEXT is made, and debugging end-users' 
configurations (okay, to build package X, you have to have 
transparent_exe unset, but for building package Y, you need it set...Oh, 
and by the way, are you using a cygwin newer than 1.5.20?  UGH!)

So, autoconf/automake/libtool will not be changed in that way.

I've already outlined the solution -- it's a lot of work, but avoids all 
of the pitfalls I've mentioned and several that I haven't bothered to, 
*AND* isolates the change to the libtool package alone without rippling 
to autoconf/automake/bazillion-other-makefiles:

    http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html

For *that*, PTC.  We're still left with *half* of the problem, and it 
won't go away: assuming my solution is implemented it's obviously only 
effective if it's used: packages using today's libtool won't work on 
new-cygwin with transparent_exe.  But, packages using new-libtool should 
work in EITHER case -- so this is a one-way incompatibility, and users 
with problems have two choices: upgrade libtool and relibtoolize, and 
your package will work everywhere, or don't use transparent_exe.

Whereas with the EXEEXT= idea, if implemented, it's a two-way 
incompatibility: newly libtoolized packages with the new-libtool would 
work ONLY with new-cygwin and transparent_exe set; older packages with 
old libtool would work ONLY if old cygwin or transparent_exe UNset. 
It's this kind of take-an-irrevocable-plunge requirement that has held 
up autoconf-2.5x penetration for going-on six years now.  That's not good.

--
Chuck