make versionitis? (OpenBSD) QUESTION TO MAINTAINERS IMBEDDED
Donn Terry
donnte@microsoft.com
Thu Nov 9 17:58:00 GMT 2000
There are several distinct items here:
1) I don't want to do this, someone else did it to me. The question
was AND REMAINS whether this is something that the gcc maintainers
wish to allow to stand in the makefile. MAINTAINERS?
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.
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.
Donn
=====================================================================
=====================================================================
To: Mr. Donn Terry
From: Andrew Josey, PASC Functional Chair Interpretations
Reference: PASC 1003.2-92 # 193
Dear Sir.
Subject: IEEE Standard 1003.2-1992
Enclosed is the official response for your request for an interpretation
of IEEE Standard 1003.2-1992.
This response was developed and approved by the members of the 1003.2
Interpretations Committee.
To obtain an understanding of the PASC Guidelines for interpretations
and their classifications please see
http://www.pasc.org/interps
Please can you confirm receipt of this electronic mail message
within ten working days, please carbon copy your response to the IEEE
(stds-pasc-ieee-officers@ieee.org)
Sincerely,
Andrew Josey
PASC Functional Chair Interpretations
Enclosures
Cc: IEEE PASC Officers
Don Cragun, Chair, P1003.2
____________________________________________________________________________
_
PASC Interpretation
reference
1003.2 #193
____________________________________________________________________________
_
Interpretation Number: xxxx
Topic: make
Relevant Sections: P 673 L 464, 477
From: Donn Terry <donnte@microsoft.com>
Date: Mon, 3 Jul 2000 13:06:05 -0700
PASC Interpretation Request:
----------------------------
From: Donn Terry
Date: 2000 June 16
Address details:
Microsoft Corporation
1 Microsoft Way
Redmond, WA
425 705-5091
425 936-7329 Fax (please include email address on cover page)
------------------------------------------------------------------------
7 Defect Report concerning (number and title of International Standard
or DIS final text, if applicable):
IEEE Std 1003.2-1992 (ISO 9945-2:1992).
------------------------------------------------------------------------
8 Qualifier (e.g. error, omission, clarification required):
3
Error=1 , Omission=2, Clarification=3
------------------------------------------------------------------------
9 References in document (e.g. page, clause, figure, and/or table
numbers):
P 673 L 464, 477
------------------------------------------------------------------------
10 Nature of defect (complete, concise explanation of the perceived
problem):
If I code
xx=aa
yy=bb
aabb=pqrs
$(xx$(yy))
Does the macro processor return pqrs or an error? Some actual
implementations do one, some the other. The distinction is
associated with the text at 464 and 467, which say rather
different things if you are thinking "macros are processed
inner-to-outer" vs. "macros are processed left to right".
For "inner-to-outer", pqrs is the right answer. For "left to right",
an error is the right answer, becase the macro call is
neither $(string1) nor $(string1:stuff).
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.)
------------------------------------------------------------------------
11 Solution proposed by the submitter (optional):
Weasel words... least restrictive means "unspecified".
Refer to sponsor for a real solution. I don't really have an opinion
except to note that openBSD's version (unless there's a recent fix)
would break if inner-to-outer were required. gmake is inner-to-outer.
I don't know about the historical System V derived makes.
------------------------------------------------------------------------
Interpretation response
------------------------
The standard does not speak to this issue, and as such no conformance
distinction can be made between alternative implementations based on
this. This is being referred to the sponsor.
Rationale
-------------
None.
Notes to project editor (not part of this interpretation):
-----------------------------------------------------------
after 466 add "If string1 contains a macro expansion, the results are
unspecified".
also after 481 add "If string1 contains a macro expansion, the results are
unspecified".
also at 473
"Macros in macro definition lines shall not be evaluated until the new macro
being defined is used in a rule or command." should change to
"Macros in string2 of macro definition lines shall not be evaluated until
the new macro being defined is used in a rule or command. Macros in
string1 of macro definition lines should be evaluated when read."
Forwarded to Interpretations group: 14 July 2000
Proposed resolution: 25 July 2000
Finalised Interpretation: 29 August 2000
-----
Andrew Josey The Open Group
PASC FC Interpretations Apex Plaza,Forbury Road,
Email: a.josey@opengroup.org Reading,Berks.RG1 1AX,England
Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
PASC Interpretations Web Site: http://www.pasc.org/interps/
=====================================================================
=====================================================================
> -----Original Message-----
> From: Marc Espie [ mailto:espie@quatramaran.ens.fr ]
> Sent: Thursday, November 09, 2000 3:34 AM
> To: Donn Terry
> Cc: gcc-bugs@gcc.gnu.org
> Subject: Re: make versionitis? (OpenBSD)
>
>
> In article
> <FE465D8F724E3F4F811D067203A214AE11AB00@red-msg-08.redmond.cor
> p.microsoft.com> you write:
> >Before I go off and try to figure out a fix (or workaround),
> what are the
> >rules of
> >engagement w.r.t. make versions?
> >
> >Specifically, recently the line
> > GCC_WARN_FLAGS= $(LOOSE_WARN) $($(@D)-warn)
> >was introduced.
>
> The standard is crystal-clear: embedded variables like what
> you're trying
> to do are NOT standard at all.
>
> This is not even a question of `fixing' OpenBSD make.
> What does OpenBSD make 1.6 means, btw ? There is NO OVERALL
> VERSION NUMBER
> in make.
>
> I can tell you that embedded variables have been added in
> recent revisions
> of OpenBSD make. Note that this is an added extra feature,
> NOT a bug-fix.
>
> Next time you spot a problem in OpenBSD make, please Cc: me,
> I read gcc-bugs
> infrequently, and I almost missed your post.
>
More information about the Gcc-bugs
mailing list