comphelper dep of officecfg

[Michael Stahl]

On 20/02/12 17:50, Norbert Thiebaud wrote:
> 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.

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