make-alpha
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding debugging to GNU make (Mailing lists are a disaster lately!)


From: Eli Zaretskii
Subject: Re: Adding debugging to GNU make (Mailing lists are a disaster lately!)
Date: 15 Mar 2004 07:53:00 +0200

> Date: Sun, 14 Mar 2004 16:50:53 -0500
> From: "Paul D. Smith" <address@hidden>
> 
> I think a debugger would be cool.

Agreed.

> My one doubt is that it would be overkill.  Do we really need something
> this interactive?  Sure, it could be very neat, and there are some very
> complex makefiles around but I still have to wonder if overall it's
> really needed.  Maybe the -E-type output would be good enough for the
> complex cases that might otherwise use a debugger.

Again, I agree.  I think the -d and -p style output, but one that
could be tailored to debugging a specific problem, would be enough.

For example, it is frequently a case that Make decides not to rebuild
a certain target, but it is hard to get it to explain why, because the
info printed by -d, even if we put aside its volume, does not really
explain itself enough.  It would be cool if Make could say something
like ``X has Y as its prerequisite, but Y is older than X, so no need
to rebuild X from Y using the rule "frobnicate X -o Y"''.  This might
sound trivial when X has only one possible way of being produced, but
in a large and complex Makefile, especially in a recursive build,
there could be dozens of possible ways of generating X, as "make -d"
shows already.  Having all those ways shown explicitly together with
Make's decisions spelled in human-readable language would ease the
task of debugging Makefile's and Make itself to a large degree, I
think.

Similarly, it would be nice to have a way to ask Make to show all the
stages of expanding a variable or perhaps all variables used in a
certain dependency and the associated rules.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]