Re: 4.4: embeds volatile information in MAKEFLAGS
Paul Smith wrote in <05f924d1e2c372b7321b6c3b1863ff864cc433df.ca...@gnu.org>: |On Mon, 2022-11-07 at 21:55 +0100, Steffen Nurpmeso wrote: |> |However, I don't think that any changes being made for GNU Make 4.4 |> |compatibility, would render the makefile unusable with GNU Make 4.3 |> |(unless they start actually using the new features like the new |> |functions, but I don't know of any projects doing so yet... of |> course |> |that doesn't mean they are not) so sticking with 4.3 shouldn't |> render |> |any projects unbuildable. |> |> To be honest i also struggled with what to do per se. We want to |> preserve MAKEFLAGS for future invocations, but now would need to |> clean it up to work around things that cause problems further on. |> (Parsing this requires understanding of shell quoting. And noone |> knows what users may want to do or use for flags.) | |I guess what I was trying to say is that you shouldn't feel pressured |to upgrade to GNU Make 4.4, yourself, if it causes problems, since it's |highly unlikely that any of the projects you're building will stop |working with GNU Make 4.3: any changes they are making to support 4.4 |will not _require_ 4.4; they will be backward-compatible with 4.3. | |You can stay on 4.3 until there's a GNU Make release that doesn't cause |such problems for you. Thanks, Paul Smith. I have not yet, for my system (only as a side installation, for testing). Some Linux distributions that matter for me personally are also waiting, but there are heavyweight distributions that already switched [1]. Gentoo is critical for my MUA, as it is source based, and the recipe will fail. (But i would not overestimate that problem, i guess very few people are using the MUA there.) [1] https://repology.org/project/make/versions --End of <05f924d1e2c372b7321b6c3b1863ff864cc433df.ca...@gnu.org> Paul Smith wrote in <4c5703754592cbe43b7d4d332d6acce82c6015d8.ca...@gnu.org>: |On Mon, 2022-11-07 at 14:59 -0500, Paul Smith wrote: |> I agree that we should drop down to "jobserver unavailable" here |> rather than having a fatal error. | |I have a change that implements this now. Thank you very much. I look forward seeing it in the repository. --End of <4c5703754592cbe43b7d4d332d6acce82c6015d8.ca...@gnu.org> Good night, and greetings from Germany! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: 4.4: embeds volatile information in MAKEFLAGS
On Mon, 2022-11-07 at 14:59 -0500, Paul Smith wrote: > I agree that we should drop down to "jobserver unavailable" here > rather than having a fatal error. I have a change that implements this now.
Re: 4.4: embeds volatile information in MAKEFLAGS
On Mon, 2022-11-07 at 21:55 +0100, Steffen Nurpmeso wrote: > |However, I don't think that any changes being made for GNU Make 4.4 > |compatibility, would render the makefile unusable with GNU Make 4.3 > |(unless they start actually using the new features like the new > |functions, but I don't know of any projects doing so yet... of > course > |that doesn't mean they are not) so sticking with 4.3 shouldn't > render > |any projects unbuildable. > > To be honest i also struggled with what to do per se. We want to > preserve MAKEFLAGS for future invocations, but now would need to > clean it up to work around things that cause problems further on. > (Parsing this requires understanding of shell quoting. And noone > knows what users may want to do or use for flags.) I guess what I was trying to say is that you shouldn't feel pressured to upgrade to GNU Make 4.4, yourself, if it causes problems, since it's highly unlikely that any of the projects you're building will stop working with GNU Make 4.3: any changes they are making to support 4.4 will not _require_ 4.4; they will be backward-compatible with 4.3. You can stay on 4.3 until there's a GNU Make release that doesn't cause such problems for you.
Re: 4.4: embeds volatile information in MAKEFLAGS
Paul Smith wrote in : |On Mon, 2022-11-07 at 21:24 +0100, Steffen Nurpmeso wrote: |> What would interest me now. Will there be GNU make 4.4.1? |> (On the left and right i see quite some changes of projects to |> become compatible with GNU make 4.4 though, CRUX Linux imported |> a pretty lengthy glibc patch, and on the ports list of OpenBSD |> there is also trouble..) | |It looks like there will probably need to be one, yes. Oh there is a sense of relief here. |However, I don't think that any changes being made for GNU Make 4.4 |compatibility, would render the makefile unusable with GNU Make 4.3 |(unless they start actually using the new features like the new |functions, but I don't know of any projects doing so yet... of course |that doesn't mean they are not) so sticking with 4.3 shouldn't render |any projects unbuildable. To be honest i also struggled with what to do per se. We want to preserve MAKEFLAGS for future invocations, but now would need to clean it up to work around things that cause problems further on. (Parsing this requires understanding of shell quoting. And noone knows what users may want to do or use for flags.) Small projects like mine can be lucky to have some packagers that care for new releases in time at all, but beside this noone will put more work in it than absolutely necessary. (There are packagers which manage dozens, or even _many hundreds_ of packages.) I could only make a new release. |Most of these changes are cleanups to always-problematic code, that |used to happen to work "by accident" but no longer does (or won't in |the future for deprecated things). I personally do not use any sophisticated make(1) constructs, no inclusions, conditionals, patterns. It is only -j and (sorts of) .WAIT. --End of Thank you, Paul Smith. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: 4.4: embeds volatile information in MAKEFLAGS
On Mon, 2022-11-07 at 21:24 +0100, Steffen Nurpmeso wrote: > What would interest me now. Will there be GNU make 4.4.1? > (On the left and right i see quite some changes of projects to > become compatible with GNU make 4.4 though, CRUX Linux imported > a pretty lengthy glibc patch, and on the ports list of OpenBSD > there is also trouble..) It looks like there will probably need to be one, yes. However, I don't think that any changes being made for GNU Make 4.4 compatibility, would render the makefile unusable with GNU Make 4.3 (unless they start actually using the new features like the new functions, but I don't know of any projects doing so yet... of course that doesn't mean they are not) so sticking with 4.3 shouldn't render any projects unbuildable. Most of these changes are cleanups to always-problematic code, that used to happen to work "by accident" but no longer does (or won't in the future for deprecated things).
Re: 4.4: embeds volatile information in MAKEFLAGS
Hello Paul Smith.
Paul Smith wrote in
<07e283aabbe6e01cc56a8d9349257ab2f125f114.ca...@gnu.org>:
|On Mon, 2022-11-07 at 20:32 +0100, Steffen Nurpmeso wrote:
|> mkdir /tmp/t
|> cd /tmp/t
|> cat > makefile <<'EOT'
|> .NOTPARALLEL:
|> .WAIT: # Luckily BSD make supports specifying this as target, too
|> config:
|> @{ echo MAKE=\"$(MAKE)\";echo MAKEFLAGS=\"$(MAKEFLAGS)\"; } >
|> ./au;echo config
|> all:
|> . ./au;echo all;$${MAKE} internal_
|> internal_:
|> @echo MAKE=$(MAKE), MAKEFLAGS=$(MAKEFLAGS)
|> EOT
|
|I see. I don't think any of us envisioned this idea of storing the
|MAKEFLAGS from a previous run and using them in a subsequent run. That
|is an interesting use-case.
The users did not want to adjust the make.rc file. Passing it via
command line is so much easier.
And then it is also that "config" fixates the -j statement, for me
personally. Changing command line flags changes the configuration
and triggers rebuilds, which is a no-go in package builder recipes
which separate the different stages (config, build, test,
install..). On the other hand want to pass the initial desire of
-j multiprocessing. The way it is one then simply says "make"
and it scales up to the desire expressed when doing "config".
|> I mean, _if_ the FIFO does not exist then "the server exited
|> gracefully", which it would not do upon crash, no? Just ignore
|> ENOENT thus? What do you say?
|
|I agree that we should drop down to "jobserver unavailable" here rather
|than having a fatal error.
That is great! Thanks!
|> Btw if it would be me, i would pass that via environment
|> variables, which makes a natural connection to a server and its
|> child clients. I mean, Linux and GNU LibC now make (some aspects
|> of) environment inaccessible for root aka SUID i think (E?UID
|> mismatches, issetuid or what-do-i-know, but this hardly is
|> a problem for GNU make.
|
|I'm not sure I understand what you are saying. These values ARE passed
|to the child clients through the environment. That's what MAKEFLAGS
|_is_, it's the environment variable that's used to allow a parent make
|to provide information on options etc. to its sub-makes.
|
|The POSIX spec says (in the Rationale):
|
|> The environment [of the child processes] is the same as the
|> environment to make except that MAKEFLAGS [...] are added
..ok. Sorry. I am definitely not in that matter.
--End of <07e283aabbe6e01cc56a8d9349257ab2f125f114.ca...@gnu.org>
What would interest me now. Will there be GNU make 4.4.1?
(On the left and right i see quite some changes of projects to
become compatible with GNU make 4.4 though, CRUX Linux imported
a pretty lengthy glibc patch, and on the ports list of OpenBSD
there is also trouble..)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: 4.4: embeds volatile information in MAKEFLAGS
On Mon, 2022-11-07 at 20:32 +0100, Steffen Nurpmeso wrote:
> mkdir /tmp/t
> cd /tmp/t
> cat > makefile <<'EOT'
> .NOTPARALLEL:
> .WAIT: # Luckily BSD make supports specifying this as target, too
> config:
> @{ echo MAKE=\"$(MAKE)\";echo MAKEFLAGS=\"$(MAKEFLAGS)\"; } >
> ./au;echo config
> all:
> . ./au;echo all;$${MAKE} internal_
> internal_:
> @echo MAKE=$(MAKE), MAKEFLAGS=$(MAKEFLAGS)
> EOT
I see. I don't think any of us envisioned this idea of storing the
MAKEFLAGS from a previous run and using them in a subsequent run. That
is an interesting use-case.
> I mean, _if_ the FIFO does not exist then "the server exited
> gracefully", which it would not do upon crash, no? Just ignore
> ENOENT thus? What do you say?
I agree that we should drop down to "jobserver unavailable" here rather
than having a fatal error.
> Btw if it would be me, i would pass that via environment
> variables, which makes a natural connection to a server and its
> child clients. I mean, Linux and GNU LibC now make (some aspects
> of) environment inaccessible for root aka SUID i think (E?UID
> mismatches, issetuid or what-do-i-know, but this hardly is
> a problem for GNU make.
I'm not sure I understand what you are saying. These values ARE passed
to the child clients through the environment. That's what MAKEFLAGS
_is_, it's the environment variable that's used to allow a parent make
to provide information on options etc. to its sub-makes.
The POSIX spec says (in the Rationale):
> The environment [of the child processes] is the same as the
> environment to make except that MAKEFLAGS [...] are added
Re: 4.4: embeds volatile information in MAKEFLAGS
Hello.
Steffen Nurpmeso wrote in
<20221105231048.8w3mb%stef...@sdaoden.eu>:
|Steffen Nurpmeso wrote in
| <20221105230326.qijdr%stef...@sdaoden.eu>:
||Dmitry Goncharov wrote in
|| :
|||On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso \
|||wrote:
|||> make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \
|||> or directory. Stop.
|||
|||Can you please tell us how to reproduce?
mkdir /tmp/t
cd /tmp/t
cat > makefile <<'EOT'
.NOTPARALLEL:
.WAIT: # Luckily BSD make supports specifying this as target, too
config:
@{ echo MAKE=\"$(MAKE)\";echo MAKEFLAGS=\"$(MAKEFLAGS)\"; } >
./au;echo config
all:
. ./au;echo all;$${MAKE} internal_
internal_:
@echo MAKE=$(MAKE), MAKEFLAGS=$(MAKEFLAGS)
EOT
If you run this
#?2|kent:y$ make -j4 config OPT_POP3=y;make all;../x/make-4.4/make -j4 config
OPT_POP3=y;make all
config
. ./au;echo all;${MAKE} internal_
all
make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
make[1]: Entering directory '/tmp/y'
MAKE=make, MAKEFLAGS=w -j1 -- OPT_POP3=y
make[1]: Leaving directory '/tmp/y'
config
. ./au;echo all;${MAKE} internal_
all
make[1]: Entering directory '/tmp/y'
make[1]: *** Cannot open jobserver /tmp/GMfifo17790: No such file or
directory. Stop.
make[1]: Leaving directory '/tmp/y'
make: *** [makefile:6: all] Error 2
I mean, _if_ the FIFO does not exist then "the server exited
gracefully", which it would not do upon crash, no? Just ignore
ENOENT thus? What do you say?
Btw if it would be me, i would pass that via environment
variables, which makes a natural connection to a server and its
child clients. I mean, Linux and GNU LibC now make (some aspects
of) environment inaccessible for root aka SUID i think (E?UID
mismatches, issetuid or what-do-i-know, but this hardly is
a problem for GNU make.
I want to point out that this build system works with _all_ known
environments back to Y2K (*BSD, Linux, Solaris, [UnixWare 7.1.4]).
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: 4.4: embeds volatile information in MAKEFLAGS
Steffen Nurpmeso wrote in <20221105230326.qijdr%stef...@sdaoden.eu>: |Dmitry Goncharov wrote in | : ||On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso \ ||wrote: ||> make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \ ||> or directory. Stop. || ||Can you please tell us how to reproduce? ... |You could, however, easily test with my mailer, the CRUX recipe is ... |^ I told him he can join the two invocations into one, this would |work with GNU make 4.4 This will not work for other Linux distributions or operating system packages, as these often separate per see, so that you have configuration, build, install, and test in separately addressable packaging rules. Ciao! --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: 4.4: embeds volatile information in MAKEFLAGS
Dmitry Goncharov wrote in
:
|On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso wrote:
|> make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \
|> or directory. Stop.
|
|Can you please tell us how to reproduce?
Well it is a bit hard in a short time.
But like i wrote in my second message.
You could, however, easily test with my mailer, the CRUX recipe is
name=mailx
version=14.9.24
release=1
source=(https://www.sdaoden.eu/downloads/s-nail-$version.tar.xz)
build() {
cd s-nail-$version
make config \
VAL_SID= \
VAL_MAILX=mailx \
VAL_PREFIX=/usr \
VAL_LIBEXECDIR=/usr/lib/mailx \
OPT_AUTOCC=no
make DESTDIR=$PKG install
^ I told him he can join the two invocations into one, this would
work with GNU make 4.4
chmod -R u+w $PKG
ln -s mailx $PKG/usr/bin/Mail
ln -s mailx $PKG/usr/bin/mail
ln -s mailx.1 $PKG/usr/share/man/man1/mail.1
}
Ciao!
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: 4.4: embeds volatile information in MAKEFLAGS
On Sat, Nov 5, 2022 at 6:24 PM Steffen Nurpmeso wrote: > make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file or > directory. Stop. Can you please tell us how to reproduce? regards, Dmitry
Re: 4.4: embeds volatile information in MAKEFLAGS
Steffen Nurpmeso wrote in
<20221105222339.z0b2x%stef...@sdaoden.eu>:
...
| #?0|kent:s-nail-14.9.24$ ../make-4.4/make all -j4
| ...
|All good
| ...
| #?0|kent:s-nail-14.9.24$ make distclean
| make[1]: Entering directory '/tmp/x/s-nail-14.9.24/.obj'
| make[1]: *** Cannot open jobserver /tmp/GMfifo31074: No such file \
| or directory. Stop.
| make[1]: Leaving directory '/tmp/x/s-nail-14.9.24/.obj'
| make: *** [makefile:40: distclean] Error 2
|
|It seems GNU make now embeds volatile information into $MAKEFLAGS,
|but refrains from working if that is invalid.
This hinders build systems which aim in being portable and easy,
in that users simply call "make" and that calls some shell script
for configuration by itself (instead of the typical GNU style
"./configure && make && make install).
I do, for example, and in the shell script i do
COMMLINE="${*}"
in order to pick up things the user gave on the command line.
(The software can be configured via command line arguments, say
$ make OPT_POP3=no OPT_SMTP=require tangerine)
...
|I wonder, or, to be honest, it is my opinion that GNU make should
|reset this part of MAKEFLAGS in at least the ENOENT case?
...
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
