bugmake - Bugs: bug #59169, Add a --debug=why category for the...


bug #59169: Add a --debug=why category for the -d/--debug option

Submitted by:  David Boyce <boyski>
Submitted on:  Wed 23 Sep 2020 02:22:35 AM UTC  
Severity:  3 - Normal Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  Paul D. Smith <psmith> Open/Closed:  Closed
Component Version:  4.3 Operating System:  Any
Fixed Release:  SCM Triage Status:  Small Effort

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


Sun 06 Dec 2020 07:07:54 PM UTC, comment #5: 

I'd consider this change too small to require attribution so not to worry!

David Boyce <boyski>
Sun 06 Dec 2020 03:08:57 PM UTC, comment #4: 

I added this although I reworked it a bit to remove the global trace_flag altogether, and updated the man page.  I changed the does not exist message to "target does not exist" to try to be more clear.

David, I just realized I forgot to add your name to the commit message as the original author :(  So sorry about that... :( :(

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Mon 28 Sep 2020 02:41:26 PM UTC, comment #3: 

I've updated the patch a bit to coalesce message style. The current --trace output comes in one of two formats:

Makefile:12: target 'foobar' does not exist
Makefile:15: update target 'hello.o' due to: hello.c

According to whether there's a valid $?. This is unsatisfying for a few reasons:

1. Having two different formats for the same type of output with no common keyword makes trace output inherently harder to find reliably either visually or via grep et al.

2. In fact it's not at all clear to the newbie, without inspecting GNU make source code, that the "foobar does not exist" message is part of --trace output at all since "file does not exist" is one of the more common error conditions across the SW industry and could be printed by any number of unrelated recipes.

3. The message isn't anchored in time: does the target not exist before or after the recipe runs? When read literally it's incorrect since the target definitely does exist by the time the user sees the message.

I think it works better when the message is either:

Makefile:12: update target 'foobar' due to: does not exist
Makefile:15: update target 'hello.o' due to: hello.c

It might read even better if "does not exist" became "nonexistent" but I decided to defer that to Paul.

(file #49877)

David Boyce <boyski>
Sun 27 Sep 2020 02:44:04 AM UTC, comment #2: 

I've posted a patch to do this. Very lightly tested but after all it doesn't add or change any functionality.

David Boyce <boyski>
Sat 26 Sep 2020 09:03:25 PM UTC, comment #1: 

I don't fully remember why I created --trace as a separate option.  I think the idea was that it would be useful for "normal users" who weren't trying to debug makefiles, but rather were trying to trace their build operations, so putting it under --debug seemed like people might not find it.  Not sure.

Probably the right thing to do is create a debug flag that is specifically for showing command lines even if they are marked as "don't print", and have a debug flag such as you've added which shows information on why a rule was rebuilt.

Then, have the --trace flag set both those options.

Paul D. Smith <psmith>
Project AdministratorIn charge of this item.
Wed 23 Sep 2020 02:22:35 AM UTC, original submission:  

This simple patch adds a --debug=why category to print the contents of $? for every recipe invoked. Extremely similar to --trace and in fact it piggybacks off the same code, the only difference being that it doesn't force the recipe to be printed like --trace does.

Implemented because I find the ability to print $? quite useful but don't want to have to print the recipe too, and --trace per se cannot be changed compatibly.

In my day job we have many recipes up to thousands of characters long so we generally silence them and print only "$(info Making $@)" by default. This makes --trace sub-optimal for us as it stands.

In fact I wonder why --trace was implemented as a standalone flag instead of a --debug category? I'm sure there was a reason but I can't think of what it might be. If it was up to me I'd consider implementing both --debug=trace and --debug=why and documenting --trace as just an alias of --debug=trace.

This needs a doc patch and so on but I'm ignoring those unless/until this idea is accepted.

David Boyce <boyski>


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

Attach Files:

Attached Files
file #49877:  debug_print_why2.patch added by boyski (4KiB - application/octet-stream)
file #49865:  debug_print_why.patch added by boyski (3KiB - application/octet-stream - Here's an updated patch which implements Paul's suggestion along with my attempt at documenting it.)
file #49845:  why.patch added by boyski (1KiB - application/octet-stream)


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.




    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-12-06 psmith StatusNone => Fixed
        Assigned toNone => psmith
        Open/ClosedOpen => Closed
        Operating SystemNone => Any
        Fixed ReleaseNone => SCM
        Triage StatusNone => Small Effort
    2020-09-28 boyski Attached File- => Added debug_print_why2.patch, #49877
    2020-09-27 boyski Attached File- => Added debug_print_why.patch, #49865
    2020-09-23 boyski Attached File- => Added why.patch, #49845

    Back to the top

    Powered by Savane 3.6