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

[Manoj Srivastava]

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

> Manoj Srivastava wrote:
>> 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.

> This sounds like a manifest.

        No, it is most emphatically not a MANIFEST. The file 
 /usr/include/stdio.h does not  generally live in the MANOFEST,

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

> This shouldn't matter since it should be up to the maintainer of the
> project to change which version of the library it's using.

        I think you are limiting yourself by thinking in terms of
 projects and maintainers. However, I am not prepared to spend more
 time trying to show you that the need for this featureset is not met
 by simple hand waving. 

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

> No, and yes.

> This is open source.  You're welcome to make the changes yourself
> without asking for approval or justifying it.

        Unless you are the person doing the work on make, this is not
 your call.

> OTOH, every added feature leads to more complex software.  More
> complex software leads to security holes and other problems.

        Sure. But this is not a major departure from what make already
 does; it does identify each node in the dag; all it has to do is
 optionally print the nodes, and stop.

>> This is not information that is readily available, and it should be
>> relatively easy for make to disseminate this information.

> I agree.  I'm not sure I agree that make should provide this
> information.  In most cases, it won't be 100%.  For example, what if
> the OS version changes?  What if the compiler version changes?

        Make is the nly one that fully knows each node in the DAG, it
 would be easiest inserted in code that is already written, and any
 external implementation would have to track the algorithm make uses,
 so yes, I do think make is the best place to put this feature in. 

> What I've done in the past is to have each project to supply a
> makefile that lists its dependencies on other projects.  Each
> project would include the published dependency makefile of its
> dependencies.  It's recursive.

        Thats bully for you. That does in no way solve the problems
 this feature request is meant to handle.

> A rule would then be invoked that would spit out the dependencies.

        So, instead of having make just list out the nodes it already
 has to determine, you think duplicating all this and complicating
 gazillions of Makefiles is more efficient? And to masintain this
 information in in the Makefiles?

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

> Then it should also be understood that some will ask for rationale
> and justification behind the feature request.

        If you are not the person who is going to do the work, this
 again is not your call.

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

> I can't speak for the maintainers of make (sorry if I inferred that
> I was).

        Then I suggest you stop trying to be a gating mechanism
 between the maintainers and user requests. Another aspect of free
 software is the community; and the feedback that authors get from
 users, and the features implemented based on user request often are
 what make software better (my code has certainly gotten more useful
 based on users requesting me to implement functionality that was
 useful to them. 

> OTOH, I hope thinking of the problem differently will solve the real
> problem at hand, that is, tracking all dependencies of projects.

        You, sir, don't really know the real problem at hand,  so
 please forgive me if I am unwilling to accept your judgement on what
 the optimal solution is. At any rate, I think this conversation is
 done; I shall wait the determination of the maintainers on this
 feature request; in the meanwhile, this report shall remain open no
 the Debian BTS.

        manoj

-- 
Hi!  I'm Larry.  This is my brother Bob, and this is my other brother
Jimbo.  We thought you might like to know the names of your
assailants.
Manoj Srivastava   <address@hidden>  <http://www.debian.org/%7Esrivasta/>
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