On 13/01/2010 15:12, Martin Hollmichel wrote: > 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 ?
i guess that if CMake does not _support_ this kind of splitting the definition of a single build definition over multiple CMakefiles, then i would expect it to not work in practice. because even if it happens to work today with some hacks and workarounds, if it is not an explicitly supported feature, some future change to CMake may break it. what we want is to split the definition of the build over several makefiles in multiple directories (so changes can be made "locally"), but then invoke some command that is able to read all of these "fragment" makefiles and check the timestamps of all the given dependencies only _once_. but of course i've never used CMake; how does CMake support this? >> Regards, >> Mathias >> >> > Martin -- I'm in search of myself. If you found me before I arrive, please have me wait. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
