bugmake - Bugs: bug #63686, implement a flag to promote make...

 
 

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

Submitter:  David Boyce <boyski>
Submitted:  Fri 20 Jan 2023 09:12:57 PM UTC
   
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.0 Operating System:  Any
Fixed Release:  SCM Triage Status:  Medium Effort
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 03 Apr 2023 12:30:11 PM UTC, comment #14: 

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

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2023 09:13:50 PM UTC, comment #13: 

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?

David Boyce <boyski>
Mon 27 Feb 2023 03:33:34 PM UTC, comment #12: 


> 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.

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2023 03:27:18 PM UTC, comment #11: 

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?

Dmitry Goncharov <dgoncharov>
Mon 27 Feb 2023 03:04:01 PM UTC, comment #10: 

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
<problematic code>
.WARNINGS: error
<everything else>

> 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.

David Boyce <boyski>
Mon 27 Feb 2023 02:06:41 PM UTC, comment #9: 

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.

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2023 02:04:32 PM UTC, comment #8: 

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.

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2023 01:56:14 PM UTC, comment #7: 

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.

David Boyce <boyski>
Mon 27 Feb 2023 04:13:10 AM UTC, comment #6: 

There are a few issues with overriding MAKEFLAGS in the makefile.

First, MAKEFLAGS are by definition passed to recursive makes.  So if you set an error flag in a parent make, it will be set in the recursive makes as well.  It would be difficult to avoid this for the user.

Second, MAKEFLAGS set inside the makefile would take precedence over flags given on the command line, because warning options are cumulative with the "last value set wins".  So if your command line said "--warn=ignore" but your makefile had "MAKEFLAGS += --warn=error", the latter would take precedence because the command line values are set first, then the addition happens when the makefile is parsed.

Paul D. Smith <psmith>
Group administrator
Mon 27 Feb 2023 03:44:50 AM UTC, comment #5: 

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

David Boyce <boyski>
Mon 27 Feb 2023 03:42:42 AM UTC, comment #4: 

I cannot think of an objection to prefer a special target as of current state. At one time manipulating MAKEFLAGS internally was dicey but I gather that as of 4.4.1 it's safe. If so, it appears that the methodologies of "special target with potential --eval option" and "command-line option with potential embedded MAKEFLAGS setting" have converged. Both would allow what I want, which is for either the user or the makefile to impose its policy (with the user winning any disagreements).

David Boyce <boyski>
Sun 26 Feb 2023 08:37:31 PM UTC, 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.

Paul D. Smith <psmith>
Group administrator
Thu 02 Feb 2023 06:34:38 AM UTC, comment #2: 

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“



Thomas Güttler <guettli>
Sun 22 Jan 2023 03:41:39 AM UTC, comment #1: 

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.

David Boyce <boyski>
Fri 20 Jan 2023 09:12:57 PM UTC, 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.

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?".

David Boyce <boyski>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by psmith (Updated the item)
  • -email is unavailable- added by guettli (Posted a comment)
  • -email is unavailable- added by boyski (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-04-03 psmith StatusNone Fixed
        Open/ClosedOpen Closed
        Operating SystemNone Any
        Triage StatusNone Medium Effort
    2023-02-26 psmith Fixed ReleaseNone SCM
    2023-02-26 psmith Component Version4.4.1 4.0

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code