comphelper dep of officecfg

Norbert Thiebaud nthiebaud at gmail.com
Mon Feb 20 08:50:24 PST 2012


On Mon, Feb 20, 2012 at 10:20 AM, Stephan Bergmann <sbergman at redhat.com> wrote:
> [including LO ML on cc, hope you don't mind; context for new readers:
no problem.

> 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.
>

a fifth solution would be to have a pseudo-module with these kind of
susequent test that can't really be run in isolation/partial build of
s single module.
make that module depend on the needed module being 'delivered',
including the header side.. that should block any compile long enough

Norbert


More information about the LibreOffice mailing list