Jussi Pakkanen wrote:
On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens t...@openoffice.org wrote:
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
Thorsten Behrens wrote:
bjoern michaelsen - Sun Microsystems - Hamburg Germany wrote:
But the actual information contained in the above lines is actually
this:
rscdep source files: tools/bootstrp/*
rscdep link libs: tl
Quoting a band from Hamburg: Jein (=Yes and No).
Of course,
Thorsten Behrens wrote:
Given that the syntax of the build task description language should
be simple (because, if one needs it to be complex, one is likely Doing
It Wrong(tm)) I wonder, if something that can be processed by the
POSIX-shell or the C-Preprocessor would not be possible too(*).
Mathias Bauer wrote:
Jussi Pakkanen wrote:
On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens t...@openoffice.org wrote:
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
On Wed, 13 Jan 2010 15:12:40 +0100
Martin Hollmichel martin.hollmic...@sun.com wrote:
Mathias Bauer wrote:
So the only way to reuse CMake makefiles for a complete build is
recursively calling them or - as we do today in OOo - serialize the
process. I don't think that this is a matter of
On Wed, Jan 13, 2010 at 5:21 PM, bjoern michaelsen - Sun Microsystems
- Hamburg Germany bjoern.michael...@sun.com wrote:
Mu. As long as you have a recursive build process, you have a lot of
implicit dependencies and those are hurting parallelization. On top of
that, process instantiation and