Martin Hollmichel
Wed, 13 Jan 2010 06:13:31 -0800
Mathias Bauer wrote:
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.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 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.
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: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org