bug#26033: EXEEXT not exported to tests

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#26033: EXEEXT not exported to tests

Peter Selinger
This bug is distinct from #26031 that I just reported.

Summary:
========

"make check" does not export the value of $(EXEEXT) to individual
tests when they are run. The tests require this information, for
example when they are shell scripts starting up executable programs
to be tested.

To reproduce:
=============

Please see the attached minimal example testing2-0.0.tar.gz

The following succeeds:

$ ./configure
$ make check

The following fails (note: it is important to run "make clean" before
"./configure ac_cv_exeext=.exe", because otherwise the generated
execuable src/someprogram will not be cleaned up):

$ make clean
$ ./configure ac_cv_exeext=.exe
$ make check

The check/test-suite.log (also attached) basically says that
../src/someprogram was not found. Although the test script
check/mytest2.sh specified ../src/someprogram$EXEEXT, the EXEEXT
setting was not exported to the script.

The following succeeds:

$ ./configure ac_cv_exeext=.exe
$ make EXEEXT=.exe check

But it seems wrong that EXEEXT should have to be specified *both* at
configure and make time.

Proposed solution:
==================

The problem goes away if the maintainer inserts

"export EXEEXT"

at the beginning of check/Makefile.am. However, I believe this should
be inserted automatically by automake, because EXEEXT must normally be
available to tests.

testing2-0.0.tar.gz (141K) Download Attachment
test-suite.log (498 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#26033: EXEEXT not exported to tests

Hans-Bernhard Bröker
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.





Reply | Threaded
Open this post in threaded view
|

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







Reply | Threaded
Open this post in threaded view
|

bug#26033: EXEEXT not exported to tests

Mathieu Lirzin
severity 26033 wishlist
tag 26033 wontfix
close 26033
thanks

Hello Peter,

[hidden email] (Peter Selinger) writes:

> =?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.

I have never mess around EXEEXT issues myself so maybe I am minimizing
the problem, but IMHO since this feature depends on a particular
portability test setup, it seems more appropriate to let maintainers
decide if they want to export EXEEXT in the test environments or not.

Thanks.

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37