Hi Simon, * Simon Josefsson wrote on Thu, Jan 19, 2006 at 09:42:17AM CET: > > 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
I can't reconstruct that (from non-mingw tests). Which Automake version is this? Which Automake options are in effect? > > 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. Yes, giving up non-recursive Makefiles helps here. > 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. OK, thanks for your opinion. Cheers, Ralf _______________________________________________ bug-gnulib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnulib
