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

2023-04-03 Thread Paul D. Smith
Update of bug #63686 (project make):

  Status:None => Fixed  
 Open/Closed:Open => Closed 
Operating System:None => Any
   Triage Status:None => Medium Effort  

___

Follow-up Comment #14:

I implemented both the --warn option and .WARNINGS variable.


___

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

2023-02-27 Thread 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/




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

2023-02-27 Thread 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

2023-02-27 Thread 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/




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

2023-02-27 Thread 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

2023-02-27 Thread 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

2023-02-27 Thread 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

2023-02-27 Thread 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

2023-02-26 Thread David Boyce
Follow-up Comment #5, bug #63686 (project make):

Sorry, previous comment should read "I cannot think of an reason to prefer
...".


___

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

2023-02-26 Thread Paul D. Smith
Update of bug #63686 (project make):

   Fixed Release:None => SCM

___

Follow-up Comment #3:

I have implemented a comprehensive method of controlling warnings in general,
including setting the action to take to "ignore", "warn", or "error", and also
added a few new warnings, which should be available in the next major
(non-bugfix) release (this is not committed yet it's in my local repo).

I implemented it as a flag "--warn..." not as a special target.  Of course you
can always use "MAKEFLAGS += --warn..." in your makefile.

If there are reasons to want a special target please let me know.


___

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

2023-02-26 Thread Paul D. Smith
Update of bug #63686 (project make):

   Component Version:   4.4.1 => 4.0


___

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

2023-02-01 Thread Thomas Güttler
Follow-up Comment #2, bug #63686 (project make):

[comment #0 original submission:]
> GCC has a -Werror option causing warnings to be promoted to fatal errors
which I (and my organization) find very useful. As a matter of policy we
always build with -Werror on and while this, obviously, is painful to start
with it leads to a much calmer working environment once cruising altitude is
reached. We find new issues much quicker since new warnings aren't
interspersed with hundreds of pre-existing ones.


Same here. Every automated way to get better quality help us in the long run.

It would help us if we could promote warnings to fatal errors.

For example:

> Makefile:118: Warnung: undefinierte Variable „FOO“




___

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

2023-01-21 Thread David Boyce
Follow-up Comment #1, bug #63686 (project make):

If this was going to be implemented, I suggest doing it as a special target
e.g. .WERROR: which would allow maximum flexibility. A proprietary build
system could embed this in their makefiles, and for open-source projects or
other cases where it should be optional it could be handled as a command-line
flag via "-E .WERROR:".

I could probably provide a patch for this if it seems like a good 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

2023-01-20 Thread David Boyce
URL:
  

 Summary: implement a flag to promote make warnings to fatal
errors
 Project: make
   Submitter: boyski
   Submitted: Fri 20 Jan 2023 09:12:57 PM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: SCM
Operating System: None
   Fixed Release: None
   Triage Status: None


___

Follow-up Comments:


---
Date: Fri 20 Jan 2023 09:12:57 PM UTC By: David Boyce 
GCC has a -Werror option causing warnings to be promoted to fatal errors which
I (and my organization) find very useful. As a matter of policy we always
build with -Werror on and while this, obviously, is painful to start with it
leads to a much calmer working environment once cruising altitude is reached.
We find new issues much quicker since new warnings aren't interspersed with
hundreds of pre-existing ones.

I've been observing some GNU make warnings (introduced by a co-worker :-) in a
local build here for a while now:

warning: overriding recipe for target ...
warning: ignoring old recipe for target ...

Which made me think "wouldn't it be nice if there was a -Werror equivalent for
make?".







___

Reply to this item at:

  

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