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

[Manoj Srivastava]

On Wed, 27 Aug 2003 16:06:16 -0400, Noel Yap <address@hidden> said: 

>> 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?

> I still don't understand.  make checks timestamps of dependencies
> and does nothing if dependencies are up to date.  What do you
> propose to do?  How will your proposal be less resource intensive?
> If it is less resource intensive, why not make it part of make?

        What if I have a build machine, where several dozen projects
 of my software house are kept. I want a database of reverse
 dependencies, where every file that is changed gives a listing of
 targets and hence programs that would be affected. 

        So, whenever someone wants to change a core file, the data
 base provides information of the products and executables that would
 be affected by the change. 

        I can think of other situations where a listing of all
possible prerequisite for a target could be useful. (Changing
copyright for an included header file: how many projects does it
impact?  If we found a security hole in a structure or function: how
many projects would be impacted? All these are what if scenarios). 

        In any case, is this really necessary? Should every feature
 requester have to rigorously defend the need for a well defined,
 distinct feature? This is not information that is readily available,
 and it should be relatively easy for make to disseminate this
 information.

On Wed, 27 Aug 2003 22:11:36 +0200, Sam Ravnborg <address@hidden> said: 

> Do you think of: `$?'
>      The names of all the prerequisites that are newer than the
>      target, with spaces between them.  For prerequisites which are
>      archive members, only the member named is used (*note
>      Archives::).

        This only tells me of what needs be done to rebuild the
 target, not a listing of all possible prerequisites, which is what is
 being requested.


>> 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.

> I think such a feature would be nice for documentation purposes but
> I still don't understand your purposes.  OTOH, I could just parse
> the output of "make -npr".

        Yes, that is one process. But make -npr produces lots of
 verbiage, and it is not easy to parse the output -- though this is
 the hack one must resort to, for the moment, lacking this feature
 set in make. 

> Anyway, since this is open source, your always welcome to contribute
> a patch.  Otherwise, there's a very small possibility that someone
> else will create the patch for you.

        *Shrug*. I know how free software works. This is why this is
 labelled a "feature request", not a feature demand.  However, some
 authors of free software, myself included, do like to solicit feature
 requests from users.  I understand that there is no obligation on
 your part to listen to user request for improved functionality of the
 program in question.

        This report shall remain in the Debian Bug Tracking system, in
 the hopes that someone at a future date who has the time and
 motivation can implement this feature.

        If this is the final decision of the custodians of GNU Make, I
 would appreciate being told so, so that I can label the report
 properly (i.e, upstream, wontfix) in the Debian BTS.

        manoj
-- 
Eternity is a terrible thought.  I mean, where's it going to end? Tom
Stoppard
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