[bug #63686] implement a flag to promote make warnings to fatal errors

[David Boyce]

Follow-up Comment #7, bug #63686 (project make):

It almost sounds like you're making the case against your own proposal now
:-). Given what you say, what's the reasoning for doing this as a --warn...
flag vs a special target? I trust your judgment but I don't quite understand
it.

Parenthetically, "--warn=warn" seems a little ... weird. OTOH, as the presumed
default I guess it would be seen quite rarely. And I don't have a better idea.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

[Paul D. Smith]

Follow-up Comment #8, bug #63686 (project make):

I'm just trying to be clear about what is available, and the tradeoffs.  Maybe
some of these are not interesting to consider.

There is an argument to be made that requiring every individual makefile to
include its own .WARNINGS: special target (or whatever we decide to call it)
will be unpleasant; if someone forgets to add that to some makefile then they
won't get any warnings there and that would be frustrating.  It would be like
having to remember to add a special #pragma to every source file else you
can't get any warnings from the compiler.

Regarding the option, using "--warn" is the same as "--warn=warn".  So I
wouldn't expect the latter to be used often.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

[Paul D. Smith]

Follow-up Comment #9, bug #63686 (project make):

One other thing: obviously a special target can't be in effect until it
appears in the makefile, unlike a command line option which is always in
effect.

That means that if you didn't put that special target right at the top of a
given makefile, you could miss warnings.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

[Dmitry Goncharov]

Follow-up Comment #11, bug #63686 (project make):

Paul, if you decide to do the special target, do you intend to let that
special target have prerequisites, e.g. targets for which the feature is
enabled?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

[Paul D. Smith]

Follow-up Comment #12, bug #63686 (project make):

> Paul, if you decide to do the special target, do you intend to let that
special target have prerequisites, e.g. targets for which the feature is
enabled?
No, the prerequisites of the special target are the warning control options:

.WARNINGS: error undefined-var:ignore


> it's worth considering which model is more flexible in a cooperative
arrangement.
Well, we could always support both :)

If you set warnings on the command line they'd be in MAKEFLAGS and be in
effect for recursive invocations.

If you add a special target, those values would NOT be in MAKEFLAGS and be in
effect only for the current makefile.

Something that might be simpler than a special target, would be a special
variable like .WARNINGS or something.  The reason I suggest a variable is that
it's much easier to manipulate it and investigate its value, save it and
restore it, etc.  Special targets are static and tricky to work with.

The downside of a special variable is deciding how it should be considered WRT
delayed expansion etc. is more complex (can you make a target-specific
variable assignment that's in effect only for that target for example?)

But of course, it could be that we go to a lot of trouble to support
capabilities that people won't really care about anyway.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Pattern rules and '/'

[Frank Heckenbach]

GNU Make 4.4.1

According to the manual, in pattern rules, "the '%' matches any
nonempty substring". Accordingly, I'd have expected this Makefile:

  all: foo-bar/baz
  foo-%:; echo "$*"

to echo "bar/baz". But instead, I get:

  make: *** No rule to make target 'foo-bar/baz', needed by 'all'.  Stop.

After some further reading, I found this:

  When the target pattern does not contain a slash (and it usually
  does not), directory names in the file names are removed from the
  file name before it is compared with the target prefix and suffix.
  After the comparison of the file name to the target pattern, the
  directory names, along with the slash that ends them, are added on
  to the prerequisite file names generated from the pattern rule's
  prerequisite patterns and the file name. [...] Thus, 'e%t' matches
  the file name src/eat, with 'src/a' as the stem.

That seems rather strange to me (in which case would you want
"src/a"?), and IMHO contradicts the first statement quoted above,
and that's apparently the reason for my problem.

My actual use case is something like this (greatly simplified):

  DIRS = foo bar baz
  all: $(addprefix recurse-, $(DIRS))
  recurse-%:; $(MAKE) -C "$*"

This has worked well for a long time while I had only single-level
subdirectories. Now that I added some second-level subdirectories,
it broke with the message above.

Now, it seems I can work-around this problem using suffixes instead
of prefixes, like this:

  DIRS = foo bar baz foo/qux
  all: $(addsuffix -recurse, $(DIRS))
  %-recurse:; $(MAKE) -C "$*"

But before I start making those changes (I have a number of those
rules in various Makefiles, so it'll be a bit of work), I'd like to
clarify:

- Is this actually the expected behaviour of make, not a bug?

- What is it useful for?

- Will using suffixes avoid the problem reliably, or are there any
  other pitfalls to be aware of?

- Can you please point out this problem in the manual more clearly
  (like at the first quote above)? As is it, it reads like a lot of
  commercials, making a big promise first and in the fine print
  (on another page), adding limitations. If I'd known this before,
  I could have used suffixes from the start and avoided that extra
  work now.

[bug #63686] implement a flag to promote make warnings to fatal errors

[David Boyce]

Follow-up Comment #10, bug #63686 (project make):

Again, I'm generally ok with your implementation. No big objections, but in an
attempt to carry these discussions to closure:

> MAKEFLAGS are by definition passed to recursive makes ...

My $dayjob builds, among other things, a Linux kernel module. Kernel modules
must be built within the context of the Linux kernel build model. We have a
wrapper makefile which populates the appropriate corner of a kernel tree with
our files and then recursively invokes the kernel build system with flags
saying "build this module for this kernel". The upshot is that if we put
"MAKEFLAGS += --warn=error" in our setup makefile it would be inherited into
the Linux kernel system which may or may not handle it well. Of course this is
just one example of the general class of cases where recursing into a
third-party build model is necessary.

It could be worked around ($(MAKE) MAKEFLAGS="$(patsubst ...)" ...) but it's
worth considering which model is more flexible in a cooperative arrangement.

> A special target can't be in effect until it appears in the makefile, unlike
a command line option which is always in effect.

Is it possible to imagine a scenario where a particular warning must be
tolerated while we still want "error" behavior in general? Demoing with the
special target syntax:

.WARNINGS: ignore

.WARNINGS: error


> There is an argument to be made that requiring every individual makefile to
include its own .WARNINGS: special target (or whatever we decide to call it)
will be unpleasant ...

This seems like the flip side of what I mentioned above. AFAICT the difference
between --warn/MAKEFLAGS and .WARNINGS:/-E matters only in recursive
invocation, and in that case not having the behavior transmitted automatically
could be seen as a feature as well as a bug.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #63686] implement a flag to promote make warnings to fatal errors

[David Boyce]

Follow-up Comment #13, bug #63686 (project make):

Hmm, this is a dizzying array of choices! Since 4.4.1 is gone and this feature
will only be in the next full release which is presumably far off still, it
seems there's no rush to decide. Maybe push it as is to let people play with
it in beta form?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/