[Libreoffice] compilation failed in lotuswordpro

[Bjoern Michaelsen]

On Sat, 16 Apr 2011 20:16:07 +0100
Caolán McNamara <caolanm at 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