Re: comphelper dep of officecfg

[including LO ML on cc, hope you don't mind; context for new readers: 
officecfg/CppunitTest_officecfg_cppheader_test.mk requires 
officecfg/qa/cppheader.cxx, which indirectly includes headers from 
higher up the module hierarchy; plain "make" build logs show that the 
cxx is needlessly compiled, causing errors due to missing headers in a 
clean build, but does not cause the overall build to fail]

On 02/19/2012 10:44 PM, Norbert Thiebaud wrote:
> the confusion is that subsequentcheck is a runtime-dependency: the
> check is _run_ after all build... but it does not block the 'build' of
> the check itself.

Is that a bug or a feature?  (I now vaguely remember it was once added 
on purpose, probably so that new code that would syntactically break 
subsequentcheck would even be discovered in a non-subsequentcheck build. 
 But I think it is counter-intuitive.)

> and there is nothing that block the compile of the qa/cppheader,
> nothing that tell make that that object need FirstStartWizard.hxx not
> is there any dep to tell the compiler that the later also need
> comphelper's headers...
>
> /me disabled the unittest for now

The situation is as follows:

* officecfg/Package_cppheader.mk generates C++ headers that include 
comphelper/configuration.hxx

* comphelper depends on officecfg (so that it can use the headers 
generated there)

* officecfg/CppunitTest_officecfg_cppheader_test.mk wants to compile 
officecfg/qa/cppheader.cxx which includes all the headers generated in 
officecfg, to make sure the generated headers are syntactically valid

Does anybody have an idea how to solve this elegantly?

One solution might be to undo the mechanism by which a cxx only needed 
in subsequentcheck is nevertheless already built by a plain "make" (see 
above).

Another solution might be to somehow manually add the knowledge that 
compiling officecfg/qa/cppheader.cxx depends on 
comphelper/configuration.hxx (and so would need to be delayed until the 
latter is available, resp. would need to be skipped in a partial build).

Both these solutions have the drawback that they keep testing the 
generated headers only rather late during the build, when other places 
that use them have already encountered any generation errors, anyway.

A third solution might be to move comphelper/configuration.hxx further 
down in the hierarchy, so that officecfg can properly depend on it.  But 
there seems to be no appropriate module in existence already (above URE 
but below comphelper), and adding a module/library just for that little 
code seems overkill.

A fourth solution might be to move the unit test and accompanying cxx 
from officecfg to comphelper.  But that is inelegant in that the cxx 
contains a list of all xcs in officecfg/registry/schema, which need to 
be kept in sync manually, which in turn becomes even more of a trouble 
if the former and the latter are spread across different modules.

Stephan