On 06/29/2011 01:19 AM, Greg Stein wrote:
On Tue, Jun 28, 2011 at 16:10, Michael Stahl<[email protected]> wrote:hi all, one thing that is currently unclear to me is whether/how Apache OOo may depend on code licensed under a Category B license. the most prominent specimen of this category is the MPL. first, about OOo: how we currently build external libraries: the external libraries are not checked into the HG repository; they reside (as source tarballs) on some FTP server. the repository contains things to build the external library: * a fetch_tarballs.sh script, which is executed as part of "bootstrap" and downloads all the tarballs * for every external library, a module, containing: - patches to fix bugs that affect OOo - patches to backport security fixes (taken from upstream) - patches to make it build in our environment (especially on windows) - more bizarre patches :) - a makefile.mk to drive the build: call configure with proper flags, then make, ... - dependency metadata (prj directory) during the build, the downloaded external library tarball is unpacked, built, and the binaries and headers copied to a global directory. one thing should be perfectly clear: if there is an external C/C++ library that builds in our environment on all platforms without needing to be patched, then i haven't seen it; i don't think such a creature exists. of course for all the external modules it's possible to tell configure to not build the module in OOo but instead use the library on the system (which in many cases of course only works on GNU/Linux or *BSD).This process sounds exactly like what the "buildout" tool[1] is designed to handle. It seems like a good opportunity to move from OOo's homegrown system to something that is supported, documented, and maintained by others.
The system we currently have is effective - and it works now. I agree that there are better and more standard ways to do this but I guess it's not our first priority, maybe not even our second. It's a whole lot of stuff and it has to work on Windows as well.
Introducing something as buildtools will be the perfect time sink for someone overhauling the build process. And I would hate it if the change would stop somewhere in between - I've seen many tries to standardize stuff in OOo which ended prematurely leaving us with *two* ways to do things. It's very easy to underestimate the effort given the sheer size of OOo.
Of course if someone is willing to do this, that would be great. But it takes a lot of commitment to see the changes through.
Reviewing those patches would also be good. Try and get more of them upstream. For example, I saw some patches to Neon in there which should get pushed upstream, and also move to the latest version of Neon.
Always a good idea to do this, but if I remember right especially neon was occasionally unresponsive regarding some of our patches. But I guess every downstream project complains about upstream being unresponsive :-). But I know that we've updated neon support regularly over the last years.
Heiner -- Jens-Heiner Rechtien
