On 25 February 2013 10:52, Stephan Bergmann <[email protected]> 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 :-) > (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. make <module>.all should work just fine now and also in the future. We don't need module dependencies for that. Each target lists its dependencies and gbuild knows about all of them. > (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. HTH, Matus _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
