RE: make versionitis? (OpenBSD) QUESTION TO MAINTAINERS IMBEDD ED

[Donn Terry <donnte at microsoft dot com>]

Having been involved in the standards process for quite some time,
the key phrase in the interpretation was "the standard does not
speak to the issue".  That's the code phrase for "we blew it,
it doesn't say, does it?".  (I've written a few of those myself.)
The IEEE rules are quite explicit; when the standard doesn't speak 
to the issue "no conformance distinction can be made".  That says
that implementations can do it either way (or as many ways as they
can invent).  It says that applications can't count on anything.  

If the interpretations committee had felt that I was wrong and the
standard WAS clear, they would have said: "The standard is clear on
the subject <here's why>", and neither referred it to the sponsor
nor suggested corrected wording.  (In this case they're suggesting
the weasel words, which is OK, but never my favorite choice.)

Donn

-----Original Message-----
From: Marc Espie [mailto:espie@quatramaran.ens.fr]
Sent: Friday, November 10, 2000 12:20 AM
To: Donn Terry
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: make versionitis? (OpenBSD) QUESTION TO MAINTAINERS IMBEDD
ED


On Thu, Nov 09, 2000 at 05:57:15PM -0800, Donn Terry wrote:
> 2) 1.6 is in the source as the RCS version for OpenBSD; it's the best I
> have to identify the version.  (There's an ifdef for another version
string,
> but this is from OpenBSD, so that's the applicable one.)  That may not
make
> it unique, but it's something.

RCS version number: there is one per source file of make. Unless you give
all version numbers of all source files, you don't get anything.

> 3) I'd say that the standard is NOT crystal clear; as I noted I'd run
> across this before: the response to the official interpetation request
> I submitted follows.


If it's not written down in the standard, it's because it's not standard.
This is what your interpretation request says.

> Does the macro processor return pqrs or an error?  Some actual
> implementations do one, some the other.  
[...]

> A strict left-to-right interpretation is probably simpler, but not
> as useful, and existing makescripts (demonstrably) do use the
> inner-to-outer interpretation.  (Gnu libstdc++-v3 as of 7/01, at least.)

There you have it: they don't say those implementations are non-standard.
They only say that some makescripts exist which use the feature. They
don't commit as to the validity and portability of those Makefiles.


As far as I'm concerned, I'd really like this feature out. gcc is not
supposed to require gnu-make to build (chicken and egg problem, and there
is still a significant proportion of makes out there that don't recognize
embedded variables.


As far as implementations go, doing embedded variables without some 
noticeable performance degradation is not quite obvious.