Show module dependencies

[Stephan Bergmann]

On 02/26/2013 05:20 PM, Matúš Kukan wrote:
> On 25 February 2013 10:52, Stephan Bergmann <sbergman at redhat.com> wrote:
>> With the need for dmake and build.pl almost gone, I assume that we will want
>> to dump */prj/build.lst files and expressing inter-module dependencies via
>> them, too.  That leaves the question how we want to be able to track
>> inter-module dependencies in the future.  Specifically, what I am looking
>> for is a command (e.g., make target) to show all the modules that some given
>> module depends on, to help me decide into which module to put newly
>> developed functionality.
>
> I am afraid we need to continue maintaining these dependencies manually.
> Maybe something like $(call gb_Module_use_modules,sal,external boost cppunit)
> instead of sal/prj/build.lst.
> In gbuild nothing depends on a module; only on its targets - but the
> target does not know into which module it belongs.
> I hope this makes sense :-)

Doing that manually is maintenance trouble.  Especially given that due 
to the way our *.mk files are placed into modules, the information which 
target belongs to which module effectively /is/ there.  So it would be 
great if it were possible for a given set of targets (see below) from 
one module to compute the (convex hull of) modules where all the 
prerequisites originate from.

>> (Even if this information were no longer relevant
>> for gbuild---what is the future story of "make <module>.all"?---we will IMO
>> nevertheless want to keep module dependencies from turning into a cyclic
>> ball.)
>
> test and vcl are already depending on each other I think.

That's because each module can declare four different sets of targets, 
namely "build," "unitcheck," "slowcheck," and "subsequentcheck."  And if 
you look at modules decomposed into individual target sets instead of at 
whole modules, the dependencies still need to form a DAG.

>> (Btw, top-level "make help" advertises "showdeliverables" and "showmodules"
>> targets, the latter of which looks relevant here, but neither of them
>> works.)
>
> They should both work (I wouldn't trust that 'showdeliverables' lists
> all the files)
> but not as a toplevel target. Only inside a module.
> 'showmodules' is now pointless, it was used to identify modules from tail_build.

OK, cleaned that up now with 
<http://cgit.freedesktop.org/libreoffice/core/commit/?id=823ef20035b82a9ec5f9e1006877670f7ee64750> 
"Clean up deliver, showdeliverables, showmodules targets."

Stephan