Re: ok, new libtool for cygwin updates

[Akim Demaille]

>>>>> "tailbert" == tailbert  <edward> writes:

>> Rather the proper fix seems to have the failing tests include
>> AC_EXEEXT and AC_OBJEXT in their configure.in.

tailbert> Akim, I mean in the general case, even outside of the test
tailbert> cases. On windows platforms, executables get a .exe
tailbert> extension. The problem is, how do you create a proper "make
tailbert> clean", etc. rule? Since there is *already* a hack in
tailbert> automake.in to support EXEEXT until autoconf support for
tailbert> that is released, I suggest putting *another* temporary hack
tailbert> that at least initializes EXEEXT properly on windows
tailbert> platforms. Sure, it's a hack, but hopefully a temporary
tailbert> one. 

Yes, but that's the wrongest hack one could imagine :)

tailbert> In general, I agree. There shouldn't be machine dependent
tailbert> code in automake itself, where ever possible. On the other
tailbert> hand, having EXEEXT=\n already pretty much makes it machine
tailbert> dependent.

Yes and no.  It's backward compatibility with the Autotools which have
been about *Unix* for a long while, and are now doing some efforts for
non Unices.

Still, I shall repeat myself: to launch the *dignified* handling of
EXEEXT and OBJEXT in Automake (not the Unix centrist default you
changed)), you need to use AC_EXEEXT and AC_OBJEXT in the
configure.in.  Then, again, the proper fix for the test failure you
observe consists in fixing configure.in in the *test*.