automake
[Top][All Lists]
Advanced

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

make distcheck is not using the specified compiler


From: Peter Rosin
Subject: make distcheck is not using the specified compiler
Date: Sat, 19 Jun 2010 21:54:22 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5

Hi!

I'm trying to get in position for running the testsuite on MSYS using
the Microsoft C/C++ Compiler (and don't really know what to expect).

As a first step I tried this on a fresh checkout:

./bootstrap
./configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD
make

and that triggered a distcheck of amhello in the doc subdir. What
surprised me was that even though I specified a specific compiler,
that selection didn't find its way to the distcheck. The distcheck
has this in the output of its configure run:

checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating config.h
config.status: executing depfiles commands

Notice the use of gcc.

The configure script has the following (admittedly boilerplate)
text in its --help output:

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

So, I think CC=cl should be propagated...



Further, if I work around the above by exporting CC and CFLAGS etc
instead, the make distcheck fails (or maybe some other dist related
make target) since MSVC creates a hello.exe.manifest file that isn't
cleaned up. These are the last lines of output:

make[4]: Entering directory 
`/c/cygwin/home/peda/automake/git/testing/doc/amhello/amhello-1.0/_build'
test -z "" || rm -f
test . = ".." || test -z "" || rm -f
rm -f config.h stamp-h1
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f cscope.out cscope.in.out cscope.po.out cscope.files
make[4]: Leaving directory 
`/c/cygwin/home/peda/automake/git/testing/doc/amhello/amhello-1.0/_build'
rm -f config.status config.cache config.log configure.lineno 
config.status.lineno
rm -f Makefile
ERROR: files left in build directory after distclean:
./src/hello.exe.manifest
make[3]: *** [distcleancheck] Error 1
make[3]: Leaving directory 
`/c/cygwin/home/peda/automake/git/testing/doc/amhello/amhello-1.0/_build'
make[2]: *** [distcheck] Error 1
make[2]: Leaving directory 
`/c/cygwin/home/peda/automake/git/testing/doc/amhello'
make[1]: *** [amhello-1.0.tar.gz] Error 2
make[1]: Leaving directory `/c/cygwin/home/peda/automake/git/testing/doc'
make: *** [all-recursive] Error 1

Now, I can get past this if I rm the offending file with the correct
timing but I fear that I will have the same trouble with "real" projects.
It would be nice to be able to distcheck projects with MSVC so I'm
asking if it would be possible to clean up that file. I'm not that
familiar with neither perl nor the codebase, otherwise I would have
proposed a patch, but I'm sure someone can come up with the (expected)
one-liner pretty quickly if it's deemed OK to zap
%PROGRAM%%EXEEXT%.manifest (or however it's spelled) during make clean.

But perhaps there are projects that provide a manually written
manifest file? In that case it would be pretty evil to zap the file.
Would it be possible to detect the difference between a manually
written manifest file and an auto-generated one automatically?
Maybe not zap it if it's older than the executable?

Cheers,
Peter

(1) http://lists.gnu.org/archive/html/automake-patches/2010-06/msg00082.html



reply via email to

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