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