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

[David Boyce]

Follow-up Comment #5, bug #59169 (project make):

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

___

Reply to this item at:

  

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

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

[Paul D. Smith]

Update of bug #59169 (project make):

  Status:None => Fixed  
 Assigned to:None => psmith 
 Open/Closed:Open => Closed 
Operating System:None => Any
   Fixed Release:None => SCM
   Triage Status:None => Small Effort   

___

Follow-up 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... :( :(

___

Reply to this item at:

  

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

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

[David Boyce]

Follow-up Comment #3, bug #59169 (project make):

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)
___

Additional Item Attachment:

File name: debug_print_why2.patch Size:3 KB




___

Reply to this item at:

  

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

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

[David Boyce]

Follow-up Comment #2, bug #59169 (project make):

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

___

Reply to this item at:

  

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

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

[David Boyce]

Additional Item Attachment, bug #59169 (project make):

File name: debug_print_why.patch  Size:2 KB




___

Reply to this item at:

  

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

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

[Paul D. Smith]

Follow-up Comment #1, bug #59169 (project make):

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.

___

Reply to this item at:

  

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

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

[David Boyce]

URL:
  

 Summary: Add a --debug=why category for the -d/--debug option
 Project: make
Submitted by: boyski
Submitted on: Wed 23 Sep 2020 02:22:35 AM UTC
Severity: 3 - Normal
  Item Group: Enhancement
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.3
Operating System: None
   Fixed Release: None
   Triage Status: None

___

Details:

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.



___

File Attachments:


---
Date: Wed 23 Sep 2020 02:22:35 AM UTC  Name: why.patch  Size: 1KiB   By:
boyski



___

Reply to this item at:

  

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