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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
