On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: > FYI: <http://odftoolkit.openoffice.org/servlets/ReadMsg?list=dev&msgNo=32>
Yeah, I'm very much in favour of this myself. Split the build into two parts the API stable ure stuff, and the rest. I'm trying to home-brew some hackery to fake this up. The current practical problems are of course as listed above and that to e.g. build the sdk separately from OOo and then to build OOo against that sdk+ure combination you need to have a) config_office, dmake, solenv, instsetoo_native, soltools, scp2 and readlicense_oo in both the sdk+ure and OOo build trees b) have bridges, cli_ure, codemaker, cppu, cppuhelper, cpputools, idlc, io, javaunohelper, jurt, jvmaccess, jvmfwk, offapi, offuh, rdbmaker, registry, remotebridges, ridljar, sal, salhelper stlport, stoc, store, udkapi, ure, unoil, xml2cmp, odk, sdk_oo autodoc, udm, cosv, unodevtools, jut in the ure tree b) and jvmfwk3rc and unorc are generated in the "ure" tree for both itself and for the final OOo product, as well as the forementioned .rdb files so you need to cheat and stick them into a package generated from the ure build and reuse them from inside the OOo build and then fiddle with some variables to add the sdk includes and the ure libs to the SOLARINC and SOLARLIB etc. So it's certainly kludgy to try and do it right now, but is a very attractive goal for me to be able to just rebuild the portion of OOo affected by whatever bug I've just fixed. And a nice thin edge of a wedge to make OOo more modular at build-time as well as at runtime. C. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
