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

[Noel Yap]

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.

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

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

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

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

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.

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

Currently, I'm sort of redoing this work since I'm at a new job.  The 
dependency information will include project version information as well and 
check to ensure that several different versions of one project aren't being 
used within a project.

For example, a depedency makefile might have something like:

# dependencies of proj0
PKG += proj1/1.0
PKG += proj2/2.0

# dependencies of proj3
include proj0/0.0/dependencies.mk

PKG += proj4/4.0

This example is extremely stripped down and doesn't include version checking, 
bootstrapping, and logic to decide whether to use a development copy or a 
production copy, but you should be able to get the idea.

Each version of each project will also publish the list of files it contains 
and at what version.

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

This is true unless you follow the above example.

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

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

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

Noel