The following issue has a resolution that has been APPLIED.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned
The following issue has been RESOLVED.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
Quentin Rameau wrote, on 17 Jan 2022:
>
> > A NOTE has been added to this issue.
> > ==
> > https://austingroupbugs.net/view.php?id=1505
>
> Maybe we should use a different wording for qualifying the macro state,
> like “being
Hello,
> A NOTE has been added to this issue.
> ==
> https://austingroupbugs.net/view.php?id=1505
Maybe we should use a different wording for qualifying the macro state,
like “being set” and “unset” (or “not set”) instead of
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
Geoff Clare wrote in
<20211221103814.GB12295@localhost>:
|Steffen Nurpmeso wrote, on 20 Dec 2021:
|>
|> For example CRUX-Linux has a /etc/pkgmk.conf where people can
|> define $CFLAGS, $CXXFLAGS, etc., also things like
|>
|> export JOBS=$(nproc)
|> export MAKEFLAGS="-j $JOBS"
...
The following issue has been REOPENED.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
Steffen Nurpmeso wrote, on 20 Dec 2021:
>
> For example CRUX-Linux has a /etc/pkgmk.conf where people can
> define $CFLAGS, $CXXFLAGS, etc., also things like
>
> export JOBS=$(nproc)
> export MAKEFLAGS="-j $JOBS"
>
> It is processed by the shell before the actual package is build.
> I
Gabriel Soldani wrote, on 20 Dec 2021:
>
> On Mon, 20 Dec 2021 at 11:55, Geoff Clare wrote:
> > The idea is that if make gives an error for unset macros, then the
> > *author* of the makefile will get the error during development, and
> > will not ship a makefile that depends on expanding unset
I'm not sure whether continuing to go back and forth on this is
fruitful. I certainly understand the issue under discussion but I
absolutely do not agree that it's the place of the POSIX standard to
try to remediate it by allowing implementations to fail.
As the only (as far as I'm aware)
Hello.
Geoff Clare wrote in
<20211220133200.GA25606@localhost>:
|Robert Elz wrote, on 18 Dec 2021:
|> bsd make (bmake) has a couple of macros (the doc calls what are
|> macros here variables, but they are the same thing), which default to
|> being unset, which can be set in the environment
On Mon, 20 Dec 2021 at 11:55, Geoff Clare wrote:
> The idea is that if make gives an error for unset macros, then the
> *author* of the makefile will get the error during development, and
> will not ship a makefile that depends on expanding unset macros, thus
> preventing that scenario happening
Gabriel Soldani wrote, on 20 Dec 2021:
>
> On Mon, 20 Dec 2021 at 09:16, Geoff Clare wrote:
> > Okay, I'll give you that. So the problem we are trying to prevent
> > occurs if the macro happens to be set to something unexpected instead
> > of something useful.
> > [...]
> > There is nothing to
On Mon, 20 Dec 2021 at 09:16, Geoff Clare wrote:
> Okay, I'll give you that. So the problem we are trying to prevent
> occurs if the macro happens to be set to something unexpected instead
> of something useful.
> [...]
> There is nothing to prevent a make implementation providing a
> non-empty
Robert Elz wrote, on 18 Dec 2021:
>
> bsd make (bmake) has a couple of macros (the doc calls what are
> macros here variables, but they are the same thing), which default to
> being unset, which can be set in the environment or command line,
> but which cannot be set in any Makefile, as they alter
Paul Smith wrote, on 17 Dec 2021:
>
> On Fri, 2021-12-17 at 10:11 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > Paul Smith wrote, on 16 Dec 2021:
> > > I'm somewhat nonplussed by this conversation.
> > >
> > > We have a POSIX tool, that's been in use for 45 years. All
lenn...@getcoding.de wrote, on 17 Dec 2021:
>
> Quoth Geoff Clare via austin-group-l at The Open Group:
> > They rely not only on the behaviour of make but also on macros being
> > unset by default. They are wrong to rely on the latter, because it
> > can easily not be the case depending on
Hi Robert,
> bsd make (bmake) has a couple of macros (the doc calls what are
> macros here variables, but they are the same thing), which default to
> being unset, which can be set in the environment or command line,
> but which cannot be set in any Makefile, as they alter the interpretation
> of
Hi Ukko,
> Standardising that unset variables expand to nothing doesn't mean that
> makefile authors will now be able to depend on some variables always
> expanding to the empty string. It however standardises that all unset
> variables will expand to nothing unless set in environment, builtin
To hopefully finally let this discussion end, let me point out two
more issues.
bsd make (bmake) has a couple of macros (the doc calls what are
macros here variables, but they are the same thing), which default to
being unset, which can be set in the environment or command line,
but which cannot
17 Aralık 2021 Cuma tarihinde Quentin Rameau via austin-group-l at The Open
Group yazdı:
>
> The standard could state that the result of trying to expand an unset
> macro is implementation-defined,
>
But that's not the case; the widely-adopted behavior is that unset macros
expand to empty
Quentin Rameau wrote:
> > That was the actual standard at the time, and has been ever since.
> > That POSIX doesn't contain a sentence like that is a bug in POSIX,
> > but it doesn't change the actual standard.
>
> I'm not sure about what standard you're talking, the behaviour isn't
> specified
On Fri, 2021-12-17 at 21:34 +0100, Quentin Rameau via austin-group-l at
The Open Group wrote:
> Why not allowing in the end both behaviours?
I feel like we've gone over the problem with this.
While the current standard may not guarantee that unset variables
expand to the empty string, virtually
Hi Paul, Geoff,
> > The more I think about it, the more I am convinced that an error
> > is the right thing for make to do, and I would urge you and the
> > other implementors to provide a means (e.g. a command line option)
> > to turn it on, and have manuals encourage its use.
>
> GNU make
On Fri, 2021-12-17 at 21:16 +0100, Quentin Rameau via austin-group-l at
The Open Group wrote:
> I'm not sure about what standard you're talking, the behaviour isn't
> specified in the different make implementation manuals I could read.
GNU make has an section that discusses empty variables versus
On Fri, 2021-12-17 at 21:04 +0100, Quentin Rameau via austin-group-l at
The Open Group wrote:
> Again, relying on a variable being unset was never 100% safe.
This same argument could be made about the shell.
Why don't we, while we're at it, make a change to POSIX allowing
implementations of sh
Robert,
> Date:Fri, 17 Dec 2021 19:52:37 +0100
> From:"Quentin Rameau via austin-group-l at The Open Group"
>
> Message-ID: <20211217195237.7780b91e.quinq@fifth.space>
>
> | That was just one example out of two, then you can simply use
> | make VERBOSE=set and
Hello Robert,
I'm sorry I didn't see your messages earlier, your emails were not
properly linked to the POSIX mailing list locally.
> Date:Thu, 16 Dec 2021 08:36:11 +0100
> From:"Quentin Rameau via austin-group-l at The Open Group"
>
> Message-ID:
On Fri, 2021-12-17 at 19:52 +0100, Quentin Rameau via austin-group-l at
The Open Group wrote:
> > On Fri, 2021-12-17 at 18:19 +0100, Quentin Rameau via austin-group-
> > l atThe Open Group wrote:
> > > Then one can just call make VERBOSE=set, or VERBOSE=set make -e
> > I already explained in a
Hello Paul,
> On Fri, 2021-12-17 at 18:19 +0100, Quentin Rameau via austin-group-l at
> The Open Group wrote:
> > Then one can just call make VERBOSE=set, or VERBOSE=set make -e
>
> I already explained in a previous post why 'make -e' is not acceptable.
> It's a much, much more dangerous than
On Fri, 2021-12-17 at 18:19 +0100, Quentin Rameau via austin-group-l at
The Open Group wrote:
> Then one can just call make VERBOSE=set, or VERBOSE=set make -e
I already explained in a previous post why 'make -e' is not acceptable.
It's a much, much more dangerous than allowing unset variables.
As a note,
> until now (with the advent of ?=) there has been no other way for them
> to get the behavior they want in POSIX standard makefiles.
.POSIX:
VERBOSE =
$(VERBOSE).SILENT:
That's the vay to do it in standard POSIX makefiles, isn't it?
Then one can just call make VERBOSE=set, or
On 12/17/21 5:11 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The more I think about it, the more I am convinced that an error
is the right thing for make to do,
The world is an imperfect place. It seems that few, if any, make
implementations agree. We can't start
On Fri, 2021-12-17 at 10:11 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> Paul Smith wrote, on 16 Dec 2021:
> > I'm somewhat nonplussed by this conversation.
> >
> > We have a POSIX tool, that's been in use for 45 years. All known
> > implementations of that tool provide a
On 12/17/21 5:11 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Currently POSIX does not require unset macros to expand to an empty
string. The standard is silent on the matter, so the behaviour is
implicitly unspecified.
It seems like this is an opportunity to standardize
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
Date:Fri, 17 Dec 2021 10:11:44 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20211217101144.GA11681@localhost>
| They rely not only on the behaviour of make but also on macros being
| unset by default. They are wrong to rely on the
Quoth Geoff Clare via austin-group-l at The Open Group:
They rely not only on the behaviour of make but also on macros being
unset by default. They are wrong to rely on the latter, because it
can easily not be the case depending on circumstances.
They don’t. They rely on the Makefile working
Paul Smith wrote, on 16 Dec 2021:
>
> I'm somewhat nonplussed by this conversation.
>
> We have a POSIX tool, that's been in use for 45 years. All known
> implementations of that tool provide a specific behavior. No known
> implementations of that tool provide some different behavior. Users of
I'm somewhat nonplussed by this conversation.
The goal of POSIX (as I understand it) is to standardize existing
behaviors of tools and libraries so that USERS of these tools and
libraries can feel confident that when they move to another conforming
platform, everything will still work the same
On 12/16/21 5:27 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> Chet Ramey wrote, on 14 Dec 2021:
>>
>> On 12/14/21 5:15 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>>> Paul Smith wrote, on 13 Dec 2021:
Why shouldn't we just state that
make implementations
Date:Thu, 16 Dec 2021 10:46:57 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20211216104657.GB18517@localhost>
| Using ?= would prevent make reporting an error, but it would
| reintroduce the very problem that this change in the
Date:Thu, 16 Dec 2021 10:27:49 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20211216102749.GA18517@localhost>
| The only way to be sure that a given macro will expand to an empty
| string is to explicitly set it to an empty string.
Date:Thu, 16 Dec 2021 08:36:11 +0100
From:"Quentin Rameau via austin-group-l at The Open Group"
Message-ID: <20211216083611.209af10a.quinq@fifth.space>
Sorry, this combination of statements:
| It's not safe to rely on a macro being unset, as a make implementation
Quentin Rameau wrote, on 16 Dec 2021:
>
> > Let me reiterate my example (which is used in every single automake
> > generated makefile, plus many many others) from the comment I added to
> > the issue:
> >
> > Makefiles contain this:
> >
> > $(VERBOSE).SILENT:
> >
> > Now when you run
Chet Ramey wrote, on 14 Dec 2021:
>
> On 12/14/21 5:15 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> > Paul Smith wrote, on 13 Dec 2021:
> >> Why shouldn't we just state that
> >> make implementations must expand unset variables to the empty string,
> >> which is what all
On Tue, 2021-12-14 at 10:15 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> Effectively, if a makefile expects an unset macro to expand to an
> empty string, this is a bug waiting to be triggered.
Can you clarify the reason for this position? I don't agree with it.
Is there any
On 12/14/21 5:15 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> Paul Smith wrote, on 13 Dec 2021:
>> Why shouldn't we just state that
>> make implementations must expand unset variables to the empty string,
>> which is what all implementations (that I'm aware of) do anyway?
>
> The
Date:Tue, 14 Dec 2021 10:15:12 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20211214101512.GA21879@localhost>
| The point is that any makefile that relies on an unset macro being
| expanded to an empty string is not portable. The
Paul Smith wrote, on 13 Dec 2021:
>
> Has anyone considered my comment on:
>
> https://austingroupbugs.net/view.php?id=1505
>
> ? I'm unhappy with the resolution of this issue, to allow a conforming
> make to throw an error when expanding an unset variable. No
> implementation I'm aware of
Has anyone considered my comment on:
https://austingroupbugs.net/view.php?id=1505
? I'm unhappy with the resolution of this issue, to allow a conforming
make to throw an error when expanding an unset variable. No
implementation I'm aware of does that or ever did that, and by allowing
it we're
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1505
==
Reported By:quinq
Assigned To:
62 matches
Mail list logo
