Mathias Bauer wrote:
Jussi Pakkanen wrote:
On Mon, Jan 11, 2010 at 7:57 PM, Thorsten Behrens <[email protected]> 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 guess it's now my turn to ask for sample code here. ;)
For a backend? No, sorry. I have never looked into that.
But the issue raised earlier was that because CMake's Makefiles are
recursive (or something) they are too slow, probably because automake
does it this way and is slow. I personally do not think this will be
an issue. When running on Windows, the time taken by makefiles when
changing directories is insignificant compared to the time taken by
the compiler. But I have only tried it under Virtualbox and not at all
thoroughly.
The problem is not because the makefiles "are" recursive. The problem is
that it looks if CMake does not offer a way to include all makefiles of
the whole project (or at least larger parts of it if you think about a
split build) into a single process without clashing of target names.
I can imagine that there might be a clashing of target names in a 1:1
transistion from makefile,mk to other makefiles, but I general I would
consider the existance of target name clashes as a brain node (aka bug)
which should be solved easy.
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 performance per se, it's
just that the benefit is missing we wanted to get from the new "single
make process" approach.
no need to have this if you have unique targets, I guess ?
Regards,
Mathias
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
