On Mon, Feb 20, 2012 at 10:20 AM, Stephan Bergmann <sbergman@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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.