On Mon, 2023-07-17 at 20:41 +0200, Alejandro Colomar wrote:
> BTW, could you point out the problems with the following?
>
> MAKEFLAGS += --no-builtin-rules
> MAKEFLAGS += --no-builtin-variables
> MAKEFLAGS += --warn-undefined-variables
>
> This is what I currently use, and never had a big issue w
Paul Smith wrote:
> POSIX
> reserves all targets prefixed with "." (that are not already specified
> in the standard) to the implementation. So it's fine with POSIX to add
> a pseudo target like .NOBUILTINS; no conforming makefile can use that
> target for anything else.
Thanks for explaining!
Hi Paul,
On 2023-07-17 20:35, Paul Smith wrote:
> On Mon, 2023-07-17 at 19:31 +0200, Bruno Haible wrote:
>> Except possibly that POSIX does not allow this? Then we would need a
>> pseudo-target the turns off only the non-standardized part of the
>> built-in database, say, .NO_GNU_BUILTINS. And use
On Mon, 2023-07-17 at 19:31 +0200, Bruno Haible wrote:
> Except possibly that POSIX does not allow this? Then we would need a
> pseudo-target the turns off only the non-standardized part of the
> built-in database, say, .NO_GNU_BUILTINS. And users would have to
> write:
>
> .SUFFIXES:
> .NO_GN
Paul Smith wrote:
> Or, to test:
>
> all:
>
> .SUFFIXES:
> %:: %,v
> %:: RCS/%,v
> %:: RCS/%
> %:: s.%
> %:: SCCS/s.%
Indeed, this works fine with the 'make' on FreeBSD, NetBSD, OpenBSD,
Solaris 10, and AIX.
> If we were to add something it would be a pseudo-target like:
>
> .N
On Mon, 2023-07-17 at 18:49 +0200, Bruno Haible wrote:
> It's also annyoing because it does not work portably: On FreeBSD and
> NetBSD,
> 'make' gives an error:
>
> make: don't know how to make %,v. Stop
>
> Similarly on OpenBSD:
>
> make: don't know how to make %,v (prerequisite of: %)
>
>
Paul Smith wrote:
> I do not
> usually recommend this method of clearing the default rules. There are
> issues with modifying MAKEFLAGS, especially with some older versions of
> GNU Make. And also, in some older versions setting MAKEFLAGS in the
> makefile doesn't actually take effect anyway: it
David Boyce wrote:
> You say GNUMAKEFLAGS+=-r is "invalid syntax" but I don't know quite how to
> read that. It's not invalid in the sense of causing an error, it's just
> that it would be invisible to any non-GNU make program
Indeed, sorry. You're right. I confused it with the := assignment opera
On Mon, 2023-07-17 at 11:45 +0200, Bruno Haible wrote:
> Dmitry Goncharov wrote:
> > Once the makefile author knows the makefile does not need built-in
> > rules, they should add MAKEFLAGS=-r in the makefile and
> > this will do a good service to all their users.
I'm not sure I've followed the ent
I know nothing about autotools, so I should probably stop talking, but not
quite yet.
You say GNUMAKEFLAGS+=-r is "invalid syntax" but I don't know quite how to
read that. It's not invalid in the sense of causing an error, it's just
that it would be invisible to any non-GNU make program so presuma
David Boyce wrote:
> Everything else aside, there's a profound difference between MAKEFLAGS=-r
> and MAKEFLAGS+=-r. The latter is far less destabilizing.
At least the '-n' option does not get lost by MAKEFLAGS=-r. That is,
setting MAKEFLAGS=-r and running 'make -n' does not cause the actions
to be
Everything else aside, there's a profound difference between MAKEFLAGS=-r
and MAKEFLAGS+=-r. The latter is far less destabilizing. And
yes, GNUMAKEFLAGS is definitely better for this use.
On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote:
> Dmitry Goncharov wrote:
> > Once the makefile author k
Dmitry Goncharov wrote:
> > I believe these two user goals are so different; they belong in different
> > chapters.
> ...
> In other words, i don't see a chapter on how to avoid big debug output
> without optimizing the makefile.
Wait a second. "How to avoid big debug output?" is not one of the pr
On Mon, 2023-07-17 at 09:02 -0400, David Boyce wrote:
> This raises a side question: it's quite common for glob libraries to
> support ** as meaning "search recursively", such as
> https://docs.python.org/3/library/glob.html. I'd be a bit surprised
> if gnulib's glob implementation didn't support t
On 2023-07-17 09:34, Andreas Schwab wrote:
> On Jul 16 2023, Alejandro Colomar wrote:
>
>> However, after the suggestion from Torbjörn, I've picked this workaround
>> to reduce the code. It ended up being as small as this:
>>
>> MK := \
>> $(srcdir)/Makefile \
>> $(wildcard $(MAKEFILEDI
This raises a side question: it's quite common for glob libraries to
support ** as meaning "search recursively", such as
https://docs.python.org/3/library/glob.html. I'd be a bit surprised if
gnulib's glob implementation didn't support this. Is it possible for GNU
make to support $(wildcard **/.mk)
On Sat, 2023-07-15 at 11:28 -0400, Dmitry Goncharov wrote:
> Appendix A Debug Output.
Thanks for this Dmitry; I spent some time this weekend working on a new
section of the manual that would overlap with this. However I will
definitely examine your patch and make sure the points you (and
everyone
Dmitry Goncharov wrote:
> Once the makefile author knows the makefile does not need built-in
> rules, they should add MAKEFLAGS=-r in the makefile and
> this will do a good service to all their users.
The premise "does not need built-in rules" is likely true for most Makefiles
generated by GNU Aut
On Jul 16 2023, Alejandro Colomar wrote:
> However, after the suggestion from Torbjörn, I've picked this workaround
> to reduce the code. It ended up being as small as this:
>
> MK := \
> $(srcdir)/Makefile \
> $(wildcard $(MAKEFILEDIR)/*.mk $(MAKEFILEDIR)/*/*.mk
> $(MAKEFILEDIR)/*/*
19 matches
Mail list logo
