Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 02/26/2013 05:20 PM, Matúš Kukan wrote:
On 25 February 2013 10:52, Stephan Bergmann <sbergman@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.