On Mon, Feb 20, 2012 at 10:20 AM, Stephan Bergmann <sberg...@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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to