GNU bug report logs - #26033
EXEEXT not exported to tests

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 26033 in the body.
You can then email your comments to 26033 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: selinger <at> mathstat.dal.ca (Peter Selinger)
To: bug-automake <at> gnu.org
Cc: Peter Selinger <selinger <at> mathstat.dal.ca>
Subject: EXEEXT not exported to tests
Date: Wed, 8 Mar 2017 15:52:49 -0400 (AST)

[Message part 1 (text/plain, inline)]

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 (application/octet-stream, attachment)]

[test-suite.log (text/plain, attachment)]

Message #8 received at 26033 <at> debbugs.gnu.org (full text, mbox):

From: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>
To: Peter Selinger <selinger <at> mathstat.dal.ca>, 26033 <at> debbugs.gnu.org
Subject: Re: bug#26033: EXEEXT not exported to tests
Date: Thu, 9 Mar 2017 21:46:16 +0100

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.

Message #11 received at 26033 <at> debbugs.gnu.org (full text, mbox):

From: selinger <at> mathstat.dal.ca (Peter Selinger)
To: HBBroeker <at> t-online.de (Hans-Bernhard Bröker)
Cc: 26033 <at> debbugs.gnu.org
Subject: Re: bug#26033: EXEEXT not exported to tests
Date: Thu, 9 Mar 2017 17:31:48 -0400 (AST)

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

Message #14 received at 26033 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Lirzin <mthl <at> gnu.org>
To: selinger <at> mathstat.dal.ca (Peter Selinger)
Cc: Hans-Bernhard Bröker <HBBroeker <at> t-online.de>,
 debbugs <control <at> debbugs.gnu.org>, 26033 <at> debbugs.gnu.org
Subject: Re: bug#26033: EXEEXT not exported to tests
Date: Sun, 18 Jun 2017 01:11:23 +0200

severity 26033 wishlist
tag 26033 wontfix
close 26033
thanks

Hello Peter,

selinger <at> mathstat.dal.ca (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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.