Re: [FEATURE Request] Please add an option to list all dependencies ofa target (recursively)

[srivasta]

On Wed, 27 Aug 2003 14:19:47 -0400, Noel Yap <address@hidden> said: 

> address@hidden wrote:
>>
>> On Wed, 27 Aug 2003 07:37:46 -0400, Noel Yap
>> <address@hidden> said:
>>
>> >> I would like a way to list all dependencies and subdependencies
>> >> of a given target to avoid the recursive shell function hackism
>> >> I currently have to do when using "make -pnq".
>>
>> > IMHO, don't use recursive make:
>> > http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html.
>>
>> I get a file not found error at thet URI, but the recursion is not
>> the major point here. Indeed, the recursion here may not even refer
>> to using make recursively -- the point here is to discover all the
>> targets that would be looked at when I run make. So, if the target
>> of interest is "install", which depends on "build", which depends
>> on my-program-name, which depends on main.o, which depends on
>> main.c, which depends on /usr/include/stdio.h; I want to have all
>> these dependencies listeed -- and I am justusing a simple Makefile.

> Sorry for not checking the URL.  If you're still interested in the
> paper, googling for "recursive make harmful" turns up many links.

        OK. But I think we are being bitten by semantics -- the paper
 refers to inefficiencies in complex build environments that are only
 peripherally relevant in this feature request. The solution proposed
 in the paper, a single, humongous Makefiule (even if it is practical,
 which I personally think is only practical for small projects), would
 still have the same problems determining the dependencies involved. 

        In the language of the paper, what is being requested is a
 listing of the nodes in the DAG.

>> > If I'm misunderstanding the problem, can you provide more
>> > details, please?
>>
>> All right. Suppose I want to create a wrapper around make that
>> would call make automatically when one of the files that a make
>> target depends on changes. How do I discover what those files are?

> I don't understand, make already does this.  Why not just call make?

        Perhaps because calling make is more resource heavy? Or
 perhaps the example provided was a simplified dummy example, and the
 real requirements are more complex.  Suppose the project is to
 discover and document the impact of system/file changes on
 products/programs?

>> Obviously, make knows, since when it is actually run it goes
>> through, and tests files/targets to see if they need
>> rebuilding. What is requested is a mode in which each target is
>> assumed to be in need of rebuilding, but, instead of taking any
>> action, all that is done is to print the target's name on stdout.
>>
>> I hope this is clearer.

> Yes, much clearer.  Have you tried "make -n"?

        The person requesting the feature has; but make -n only tells
 you the actions that shall be taken currently to update the target,
 not what all the dependencies are, I would not know, for example,
 that touching /usr/include/sys/time.h would cause the target to be
 rebuilt or not.

        make -np helps a little bit more, but at the expense of a lot
 of verbiage that one has to wade through.

        If it s a complex project being managed by Make, spread over
 several directories, with unknown dependencies in the Makefiles
 there, there is no easy way to determine a priori what the
 dependencies are, down the path.

        manoj
-- 
Ship it.
Manoj Srivastava     <address@hidden>    <http://www.golden-gryphon.com/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C