On 20/02/12 17:50, Norbert Thiebaud wrote: > 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.
the fourth one sounds best to me. to eliminate manual maintenance, how about a header file generated and delivered in officecfg which includes all generated configuration header files? then include that from the test in comphelper. > 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 hmmm... don't we already have enough modules? or do you mean something that only exists in a top-level makefile and is only run during full build? (isn't that equivalent to the 2nd solution above?) > Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
