incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens-Heiner Rechtien <jhrecht...@web.de>
Subject Re: Hauling in third-party code (was: Category B licenses)
Date Wed, 29 Jun 2011 11:53:41 GMT
On 06/29/2011 01:19 AM, Greg Stein wrote:
> On Tue, Jun 28, 2011 at 16:10, Michael Stahl<mst@openoffice.org>  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

Mime
View raw message