[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
multiple definition of e.g., bin_PROGRAMS
From: |
Jim Meyering |
Subject: |
multiple definition of e.g., bin_PROGRAMS |
Date: |
Wed, 02 Apr 2003 10:46:58 +0200 |
Hi Alexandre!
I noticed recently that there are two definitions of bin_PROGRAMS
in coreutils' src/Makefile.in. One that's identical to the original
in src/Makefile.am, and another, better one, that follows most of
the rules copied from Makefile.am.
Is this intentional?
That doesn't seem like a big problem, but could conceivably cause
trouble, since most of the names in the first definition lack the
$(EXEEXT) suffix, while all of the ones in the latter have it.
Of course, most uses of $(bin_PROGRAMS) will resolve to the latter,
better definition, but if someone ever does something like this
var := $(bin_PROGRAMS)
in Makefile.am, they might be surprised not to get the $(EXEEXT) suffixes.
Poking around in automake.in, I see that append_exeext does call
macro_delete (presumably to remove the original definition), but
by the time that function is invoked, it's already too late: the
first definition has been `output' via generate_makefile's call to
read_main_am_file.
For example, from automake's backsl.test,
testSubDir/Makefile.am:bin_PROGRAMS = hello
testSubDir/Makefile.in:bin_PROGRAMS = hello
testSubDir/Makefile.in:bin_PROGRAMS = hello$(EXEEXT)
The same applies to EXTRA_PROGRAMS, and probably any other
*_PROGRAMS variables that happen to be used.
I'll let you decide whether/how to fix this one :-)
Jim
- multiple definition of e.g., bin_PROGRAMS,
Jim Meyering <=