On Sat, 16 Apr 2011 20:16:07 +0100 Caolán McNamara <caol...@redhat.com> wrote:
> On Sat, 2011-04-16 at 20:58 +0200, Bjoern Michaelsen wrote: > There's a secondary issue (afaict) wrt parallel building, isn't > there ? > > i.e. gb_Module_add_check_targets of "Package_qa_cppunit" and > "CppunitTest_lotuswordpro", i.e. the test that uses the locally > generated services.rdb (in addition to the ure one) doesn't (seem to?) > depend on the custom Package rule that generates that local > services.rdb. Well, running "make -np|grep lotuswordpro_test_lotuswordpro\.so:" you find that (all in workdir): LinkTarget/CppunitTest/libtest_lotuswordpro_test_lotuswordpro.so: \ Headers/CppunitTest/libtest_lotuswordpro_test_lotuswordpro.so The header target will be completed before the cppunit lib is linked. This is because the header target depends on everything we need to compile the objects: which is our own headers and the headers of all libs we link against. The Package lotuswordpro_qa_cppunit is not much different in that regard: Headers/CppunitTest/libtest_lotuswordpro_test_lotuswordpro.so: \ Package/lotuswordpro_qa_cppunit So the Package lotuswordpro_qa_cppunit will be guaranteed to be up to date before objects from the test will be compiled. Also: CppunitTest/lotuswordpro_test_lotuswordpro.test: \ LinkTarget/CppunitTest/libtest_lotuswordpro_test_lotuswordpro.so so before the test is run it needs to be linked (obviously). So: - running the test depends on linking the test - linking the test depends on the header target of the test - the header target depends on the Package that creates the rdb thus the test wont be run before the rdb is up to date. One remaining weak point is, that gbuild does not know currently what the CustomTarget generates. So if you manually delete a file from: CustomTarget/lotuswordpro/qa/cppunit/ but not the: CustomTarget/lotuswordpro/qa/cppunit.done CustomTarget/lotuswordpro/qa/cppunit_SRCDIR.done files, gbuild wont retrigger the recursive make call. One could fix that by redeclaring in the Package file what gbuild should expect to come out of the recursive call, but that is ugly too. Or one could always trigger the recursive call for CustomTargets -- but that would slow down the rebuilds as is would be similar to what build.pl does currently. OTOH, we will hopefully not have too many CustomTargets to make that a performance issue, really. > maybe we don't really need custom rules here, its all one of a common > pattern, perhaps worth adding a gb_CppunitTest_add_component_files > sort of thing and stick the "build a local services.rdb by stripping > out "program"" into a common rule that takes its input from that and > can be a optional dependency of the gb_CppunitTest_CppunitTest rule > and can get rid then of the custom rules in sc and lotuswordpro etc. Yes, I want to get that implemented too. Best in a way that allows us to join and hack up the component files to a rdb for running from OUTDIR and also allows us to generate the rdb files for the product (e.g. postprocess/packcomponent). Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
