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