bug#26033: EXEEXT not exported to tests

[Peter Selinger]

=?UTF-8?Q?Hans-Bernhard_Br=c3=b6ker?= wrote:
> 
> Am 08.03.2017 um 20:52 schrieb Peter Selinger:
> 
> > The tests require this information, for
> > example when they are shell scripts starting up executable programs
> > to be tested.
> 
> Not really.  On the platforms where EXEEXT is non-empty, scripts do 
> _not_ need to know about it to start executables, i.e.
> 
> Trying to test the behaviour of $(EXEEXT) on platforms where it's 
> normally empty is, IMHO, futile.  This isn't an autoconf test whose 
> result one should ever override.
> 
> > Although the test script
> > check/mytest2.sh specified ../src/someprogram$EXEEXT, the EXEEXT
> > setting was not exported to the script.
> 
> You don't need $(EXEEXT) to run the executable --- only to check the 
> file, which tests won't have to do.

You are of course technically correct. Currently, AFAIK, Windows is
the only platform that uses an EXEEXT, and Windows will automatically
run "foo.exe" is "foo" is requested.

On the other hand, in preparing my package releases, I have found that
my packages often contain silly errors related to EXEEXT, like
forgetting EXEEXT in a custom autoconf macro, Makefile, or test. I
usually catch these errors when I do testing on Windows, but that is
kind of late in my pre-release process. Starting a Windows virtual
machine is very slow for me, and I prefer to catch these errors on a
non-Windows platform, because going through the trouble of running the
actual Windows VM.

Generally, configuring and building with ac_cv_exeext=.pm and/or
EXEEXT=.pm works just fine on non-Windows platforms, and helps me
catch those errors.

So maybe this is technically a feature request and not a bug.
If you decide not to fix it, it also works for me to just put
"export EXEEXT" in the Makefile.am manually.

Thanks, -- Peter