bugmake - Bugs: bug #18617, Better debugging facilities:...


bug #18617: Better debugging facilities: tracing rule invocation.

Submitter:  None
Submitted:  Thu 28 Dec 2006 02:46:29 PM UTC
Severity:  3 - Normal Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  3.81 Operating System:  Any
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Wed 17 Sep 2008 02:26:31 PM UTC, comment #5: 

I would like to draw the attention of everyone in this thread to

"Remake - GNU Make with comprehensible tracing and a debugger"

I find it an invaluable enhancement to make when debugging complex makefiles full of generated code.  Give it a try: you won't look back once you've discovered how much easier life is when you can single-step through the source of a makefile, set breakpoints, inspect variables and see the return values from called functions.


"It doesn't tell which the implicit rule is", are you sure?  The trace shows

> Trying implicit prerequisite `assert.cxx'.
> Found an implicit rule for
> `/home/stefano/src/reilabs/flash2sip/contrib/src/ptlib_2.2.1/lib/obj_linux_x86_r/assert.o'.

Therefore the implicit rule it is referring to must be of the form

%.o: %.cxx

mustn't it?

Dave Korn <davek>
Wed 17 Sep 2008 11:01:05 AM UTC, comment #4: 

I was looking for the same feature, especially I'd like to trace the invokation of implicit rules, it would be really usueful to see the implicit rule invoked and the file where it is defined.

As an use case I'm currently debugging this (make -d):

         Trying implicit prerequisite `assert.cxx'.
         Found an implicit rule for `/home/stefano/src/reilabs/flash2sip/contrib/src/ptlib_2.2.1/lib/obj_linux_x86_r/assert.o'.
           File `/home/stefano/include/ptlib.h' does not exist.
           Looking for an implicit rule for `/home/stefano/include/ptlib.h'.
           Trying pattern rule with stem `ptlib.h'.
           Trying implicit prerequisite `/home/stefano/include/ptlib.h,v'.
           Trying pattern rule with stem `ptlib.h'.
           Trying implicit prerequisite `/home/stefano/include/RCS/ptlib.h,v'.
           Trying pattern rule with stem `ptlib.h'.
           Trying implicit prerequisite `/home/stefano/include/RCS/ptlib.h'.
           Trying pattern rule with stem `ptlib.h'.
           Trying implicit prerequisite `/home/stefano/include/s.ptlib.h'.
           Trying pattern rule with stem `ptlib.h'.
           Trying implicit prerequisite `/home/stefano/include/SCCS/s.ptlib.h'.
           No implicit rule found for `/home/stefano/include/ptlib.h'.
          Must remake target `/home/stefano/include/ptlib.h'.
make[2]: Entering directory `/home/stefano/src/reilabs/flash2sip/contrib/src/ptlib_2.2.1/src/ptlib/unix'
make[2]: * No rule to make target `/home/stefano/include/ptlib.h', needed by `/home/stefano/src/reilabs/flash2sip/contrib/src/ptlib_2.2.1/lib/obj_linux_x86_r/assert.o'.  Stop.

and I don't know where to hit my head.

It doesn't tell which the implicit rule is and where the rule is defined, so it isn't that useful, with that information I wouldn't have to figure out which is the rule applied of all the possible implicit rules.

Regards and thanks for your attention.

Stefano Sabatini <stefano_sa>
Fri 11 May 2007 08:50:22 PM UTC, comment #3: 

I added a new debug statement to the "basic" debug output that specifies where the command script was found for a given target, when make starts to build that target.  For commands found in a makefile you get:

Invoking commands from <makefile>:<lineno> to update target `<target>'.

For builtin commands, you get:

Invoking builtin commands to update target `<target>'.

Paul D. Smith <psmith>
Group administrator
Mon 08 Jan 2007 09:48:16 AM UTC, comment #2: 

You may try looking at http://lists.gnu.org/archive/html/help-make/2006-10/msg00033.html.
Using the -P (preprocessing) feature shows partial expansions of $(eval) invocations.

Rafi Einstein <rafi_einstein>
Thu 04 Jan 2007 09:21:29 PM UTC, comment #1: 

I would like to piggyback on this enhancement request. I would like to see some manner of printing out the fully resolved makefile that make processes after evaluating $(foreach), $(eval), and ($call) functions. For example, consider this complicated rule, contained within a macro define:

$$(foreach file,$$($(1)_DELIVERY_INCLUDE),$$(eval $$(call delivery_include_rule),$$(file),$$($(1)_INCLUDE_DIR)$$(notdir $(file)))))

Make run with -p just prints the macro define including this, but not the actual makefile rules it expands to each time it is evaluated. I need to be able to see what it expands to as an actual rule to see if I didn't make a mistake somewhere. It would be great if there was a debug option to enable this behavior.

Darren Hiebert <dhiebert>
Thu 28 Dec 2006 02:46:29 PM UTC, original submission:  

It usually takes a lot of time to debug makefiles written by others. This is quite frequent when one downloads a program, tries to build it and gets errors. Perhaps its something small, but tracing what variable or rule is ultimately responsible for a compilation error is unnecessarily difficult. Because makefiles can invoke or include other makefiles.

So here I am proposing several flags to make that task more easy.

First: a flag to trace rule invocation.

make --debug=r

when a rule is invoked, the filename of the Makefile, the line number of the rule, and the name of the target are printed.

For instance:

Invoking rule at Makefile:83 for target 'clean'

Sometimes it might be difficult to know in what directory is the makefile. For these cases the flag "d" (directory) is proposed.

For instance, the hacker Miguel is compiling the package guess-lottery which guesses lottery results. The package has been untarred in directory /home/miguel/guess-lottery/

make --debug=r,d

When the package is compiling invoke-god.c in directory src/engine, it will print

>  Invoking rule at /home/miguel/guess-lottery/src/engine/Makefile:83 for target 'invoke-god.o'

In case the makefile is defined in file rules.mak in directory rules of the package, make would print something like:

> Invoking rule at /home/miguel/guess-lottery/rules/rules.mak:41 included from /home/miguel/guess-lottery/src/engine/Makefile:10 for target 'invoke-god.o'

Sometimes make uses implicit rules. For these cases, it should print something enough to identify the rule. Using the previous example:

> Invoking builting implicit rule for "%c: %o" for target invoke-god.o

Another additional source of problems is assignment of variables.  Even if one knows the rule that is miscompling something, it might be because of compilation flags set in a variable. But where is that variable defined? Since makefile variables are inherited across makefile invocation, and makefiles can include other makefiles, the problem can be messy.

Therefore, an additional debugging flag is proposed for tracing variable invocations. Unfortunately, the debugging flag "v" is already used for "verbose". So the letter "p" (parameter) is proposed.

The proposed behaviour is that make prints all variable assignments when this flag is set. In addition, the invoking makefile and line number are printed as well. For example:

setting CFLAGS to "-Wall -fguess-bugs" (compiler.mak:34 included from rules.mak:2 included from Makefile:10)

make debug



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

Attach Files:

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 davek (Posted a comment)
  • -email is unavailable- added by stefano_sa (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by rafi_einstein (Posted a comment)
  • -email is unavailable- added by dhiebert (Posted a comment)

    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
    2010-07-28 psmith Fixed Release4.0 3.82
    2007-05-11 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Operating SystemNone Any
        Fixed ReleaseNone 4.0

    Back to the top

    Powered by Savane 3.13-7c56.
    Corresponding source code