Re: libstdc++/68: Makefile non-portability

[Phil Edwards <pedwards at disaster dot jaj dot com>]

The following reply was made to PR libstdc++/68; it has been noted by GNATS.

From: Phil Edwards <pedwards@disaster.jaj.com>
To: donnte@microsoft.com
Cc: libstdc++-gnats@sources.redhat.com
Subject: Re: libstdc++/68: Makefile non-portability
Date: Mon, 17 Jul 2000 12:32:26 -0400

 > I'm NOT quite sure that this qualifies as a bug because
 > it does work with gmake.
 
 Well, hmmmm.  On one hand, we do list gmake as a required tool to build
 the library.
 
 On the other hand, automake is supposed to generate super-portable Makefiles
 that don't require gmake.  Putting gmake-only code in the automake input
 file defeats the purpose.
 
 On the gripping hand, gmake is absolutely required in building GCC itself,
 and the library is being designed to be built as part of that process.
 So we've assumed that gmake will always be available.
 
 As soon as we get Solaris builds working again (those are the machines I
 have access to at the moment that also have spare diskspace), I will play
 with changing the syntax and report on this note.
 
 
 >         $(EXTRA_LONG_DOUBLE_$(USE_COMPLEX_LONG_DOUBLE))
 >
 > At least the openbsd make I use normally use doesn't
 > support nested $(), and from reading POSIX.2, this (quite
 > arguably... the standard is fuzzy) is not standard.  
 > (POSIX, P673, L467).  (The unanswered question is
 > are macros evaluated inside-outward or left to right;
 > if the latter it's illegal, if the former, it's legal,
 > and the standard doesn't make it clear.)
 
 POSIX can be so fuzzy sometimes... I would argue that nested things should
 always be evaluated inside-outward rather than side-to-side, but as you say,
 it isn't mandated.
 
 Phil