Paul Smith wrote:
> It's not acceptable (to me) to only show the one newest file, not all
> files that are newer than the target, because often you want to know
> all the newer files.
You say "It's not acceptable (to me) to only show the one newest file",
and I say "A tool that shows me 3.7 KB wor
Paul Smith wrote:
> Showing the "macroexpanded make sources" is difficult because make
> doesn't just expand an entire line then parse it. Makefile syntax is
> context-sensitive so you can't know how or if to expand parts of a line
> until you've already expanded other parts. Of course make could
Paul Smith wrote:
> Maybe a version difference. I'm using 4.4.
I get the same output with GNU make 4.4 as with 4.3.
Bruno
Paul Smith wrote:
> > I get the same output with GNU make 4.4 as with 4.3.
>
> Apologies for my mistake: I'm using the latest release (4.4.1).
> I tried your test:
>
> $ make --trace mbrtoc32.o
> Makefile:1752: update target 'mbrtoc32.o' due to: target does not exist
With 4.4.1, I see this t
Alejandro Colomar wrote:
> In GNU Make, the "printf" statement is the
> $(info ...) function. Maybe you didn't know about it?
Correct, I did not know about it. I created a 'dummy' target with an
echo command...
It would be really useful to collect all these various troubleshooting
tricks in a ch
Hello Dmitry,
Dmitry Goncharov wrote:
> >I tried -d a couple of times, and it produced a ton of output, that
> >was too much for me to make sense of. Probably 10% to 20% of the
> >developers in general have trace filtering skills, that is, know how
> >to extract the essential infor
Dmitry Goncharov wrote:
> > 1) The title, and what does the user want?
> This patch is not a full-fledged troubleshooting guide.
...
> > Is that really what I want to do and should do, as a user?
> i believe, makefile authors should apply these techniques.
OK, then it's appropriate to create *thre
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
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
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
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
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
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
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!
Dmitry Goncharov wrote:
> > If a Makefile uses MAKEFLAGS=-r and
> > the Makefile in a subdirectory needs built-in rules, will the MAKEFLAGS=-r
> > setting propagate to the subdirectory?
>
> It will.
Ouch. This is usually undesired, since a developer works on one Makefile
at a time.
Together with
Dmitry Goncharov wrote:
> On Mon, Jul 17, 2023 at 5:45 AM Bruno Haible wrote:
> > And finally, MAKEFLAGS is not even mentioned in the main index of the GNU
> > Make
> > documentation [5], and only regarding "recursion" in the Variables index
> > [6].
&g
101 - 116 of 116 matches
Mail list logo
