bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $(EXEEXT) in TESTS required?


From: Simon Josefsson
Subject: Re: $(EXEEXT) in TESTS required?
Date: Thu, 19 Jan 2006 09:42:17 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

> Hi Simon,
>
> * Simon Josefsson wrote on Wed, Jan 18, 2006 at 02:01:27PM CET:
>> While testing mingw32 portability (GNU SASL now builds cleanly 
>> cross-compiled to mingw32!) I encountered the following.  It seems 
>> $(EXEXT) is required for automake TESTS variables, otherwise 
>> 'make' misses out all CPPFLAGS etc:
>
> TESTS which are also executables should be specified in check_PROGRAMS
> as well.  Often, tests are scripts.  With generated ones, it would not
> be possible to tell the difference at the time `automake' is run.  See
> `info Automake Tests' for more information about this.
>
> I think gnulib should add executable tests to check_PROGRAMS rather than
> adding $(EXEEXT) as in your example.  Maybe even better would be adding
> it to a gnulib-specific variable, and allowing the developer to add that
> to both TESTS and check_PROGRAMS -- the duplication you mention is IMVHO
> more in the eye of gnulib than of automake.

It doesn't seem to matter if I change noinst_PROGRAMS into
check_PROGRAMS, I still have to add $(EXEEXT) to the binaries in TESTS
for things to work.

TESTS += test-gc
check_PROGRAMS = test-gc

=>

make[2]: Entering directory `/home/jas/src/gsasl/lib/tests'
i586-mingw32msvc-gcc -g -O2    test-gc.c   -o test-gc
test-gc.c:26:16: gc.h: No such file or directory
test-gc.c: In function `main':
test-gc.c:31: error: `Gc_rc' undeclared (first use in this function)
test-gc.c:31: error: (Each undeclared identifier is reported only once
test-gc.c:31: error: for each function it appears in.)
test-gc.c:31: error: syntax error before "rc"
test-gc.c:34: error: `rc' undeclared (first use in this function)
test-gc.c:35: error: `GC_OK' undeclared (first use in this function)

> Which gets me to a more general point: would the additional flexibility
> gained from using gnulib-specific variables in Makefile.am snippets be
> worth its additional cost of requiring the user to associate them with
> Automake variables?  And no, I don't know a general answer here.

I wanted that earlier -- I wanted to write my own Makefile.am and
simply include a "gnulib.mk" or similar.  However, I yielded and
places the gnulib tests in a separate directory and I haven't had any
problems with that so far.

It may be useful if you want to mix gnulib files with other files in
the same directory.  Currently, gnulib pretty much assume you allocate
separate directories for gnulib that it owns completely.

So, I don't see any strong reason to do this now, even if I think it
would have been cleaner.

Thanks!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]