comphelper dep of officecfg
sbergman at redhat.com
Mon Feb 20 08:20:05 PST 2012
[including LO ML on cc, hope you don't mind; context for new readers:
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 depends on officecfg (so that it can use the headers
* 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
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.
More information about the LibreOffice