Re: Re: Building OpenOffice.org with GNU make

Hi,
>   
>> I think it's cleaner, and there's definitely not much (should I say
>> any?) redundancy left. Additionally, one can enhance the script to
>> generate makefiles for pretty much every make tool of this world,
>> including eclipse/netbeans/visual studio project files.
>>     
>
> I would like to point out that what you are doing is generating your
> own language and a build tool/generator based on that. There's nothing
> wrong with it as such, but this is reinventing the wheel again (just
> like Google's GYP). Instead of custom dmake/build.pl you would have
> custom gnumakegen/gnumake_or_something. What is the benefit you get
> from this instead of using something like CMake that already has a
> mature implementation of this functionality? Even if CMake eventually
> turns out to be too slow, would it not make more sense to write your
> own custom CMake back end rather than the configuration/generation
> front end?
>   
I second the demand for simple, readable description files.

ath the first glance, this seem very easy with cmake, it was fun 
prototyping this on Linux for the OOo tool-chain up to the idlc. 
regmerge level. A lot of writing could be saved in comparisons to Ooo 
current build system. during the prototyping I also was surprise about 
all the stuff we're doing in Ooo's makefile's (some superfluous, some 
really needed) and I was surprised that much of the stuff already is 
covered by cmake (just proved by reading the documentation, not all 
tested in reality). Things are getting a bit more complicated, if you're 
looking on some old grown specialties of OOo, e.g the generations of 
import libraries on Win32. At some stage it is useful, if not even 
required to have an cmake expert with the OOo project who can determine 
with some experience how and where to implement such one-off's of OOo.

so we still have three valid alternatives:
* renew and modernize our old dmake environment
* re-write the build environment with a more modern tool and use some 
more modern patterns
* reuse and enhance already abstract buildenv like cmake.

I'm not yet sure what will be the best way to go.
> For further information here is a Google Tech Talk about CMake and all
> related things (testing, code coverity, packaging, etc, etc) by one of
> the creators. If the build tool decision is not yet final, it is worth
> watching.
>
>   
The CPack and CTest enhancements of cmake are indeed quite impressive, a 
transition from scp to CPack would be very interesting (and kicking 
build.pl / deliver.pl and solver at the same time).

I started some time ago a cmake prototype for OOo in my spare time 
(http://hg.services.openoffice.org/hg/cws/mh6bc/) for the latest status 
please see the latest ReadMe.txt in the Source root for the most recent 
status). You're invited to join this prototype, but be warned: it does 
not work and kills your cat when try to run that :-).

Martin