This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/15390] [3.3.x] No DESTDIR for libstdc++ includes
- From: "lloyd at must-have-coffee dot gen dot nz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Jun 2004 00:59:24 -0000
- Subject: [Bug libstdc++/15390] [3.3.x] No DESTDIR for libstdc++ includes
- References: <20040512035232.15390.lloyd@must-have-coffee.gen.nz>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From lloyd at must-have-coffee dot gen dot nz 2004-06-03 00:59 -------
(In reply to comment #10)
> Providing a patch would be quite helpful, but if that doesn't happen, can you be
> a bit more elaborate on where the problem is?
A patch is not required because the problem doesn't happen with gmake and gmake
has already been made a requirement for any future release of GCC that a fix for
this bug might be targeted at.
The recursive make problem is quite well known amongst people who know about it
(sic). When using make recursively you might have a rule like this
WORLD=Wellington
all:
$(MAKE) do-all
do-all:
echo Hello $(WORLD)
When you type "make all", you get "Hello Wellington". Lovely. When you type
"make WORLD=World", you get "Hello Wellington". Oops. We just lost our $(WORLD).
This is because Solaris (and probably most other) makes export the make
variables as environment variables, but those get overridden by the Makefile.
Some make commands do magic to work around this wart. They know that when the
user says "WORLD=World" on the command line, then they want the "World".The
NetBSD make examines its command line parameters and stores variable
assignments. Whenever it sees a rule trying to run make it rewrites the rule
internally to include these variable assignments on the command line. You can't
normally see it do this.
Some of the Makefiles in GCC have a workaround for makes that do not do this
variable assignment magic. All recipes that run $(MAKE) look like this
target: this that the-other
$(MAKE) $(AM_MAKEFLAGS) build-target
And the the AM_MAKFLAGS variable is set to a series of variable assignments for
every variable that might be used on the command line. It's usually a fairly
long list. Something like this
AM_MAKEFLAGS="DESTDIR=$(DESTDIR)" "AR_FLAGS=$(AR_FLAGS)" ...
The dodgy Makefiles have $(AM_MAKEFLAGS) in recursive rules, but they never set
AM_MAKEFLAGS. As far as I can tell all the Makefiles use AM_MAKEFLAGS, but only
about half of them define the variable.
But as I said, GNU make doesn't require this explicit support for setting make
variables on the command line and GNU make is now required.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15390