On Tuesday 28 September 2010, David Cole wrote: > Ambitious. I like it. > > I would prefer seeing this implemented as a CMake-language function. And
You mean to implement this as a cmake script, and not as a built-in function ? > adding anything necessary to CMake in order to support implementing it in > the CMake language. > > (Because I think that adding such support would also enable a slew of other > unthought-of-as-yet functionality that will prove extremely useful...) > > However, if that's not possible, or not your cup of tea, I would not fight > against including a native command to implement this functionality. > > One problem I foresee with this right from the get-go is that it is very > complex and will be difficult to test well. And possibly difficult to > figure out what's gone wrong when something does go wrong. > > You have time to prototype this in the CMake language and tell us what new > functionality we'd need to support it there? (I can tell we'll need > commands to iterate projects and targets... any others needed?) I think just a way to get a list of projects and of targets in a project wouldn't be enough. I would need * get the list of projects (easy) * I must be able to check whether project A is contained in project B * I need the targets per project (easy) * I need to figure out the dependencies between the projects/the contained targets. I'm not sure I want to do that in cmake script. or I need a way to get the projects a project depends on (or the targets a project depends on and then figure out in cmake-script to which projects these targets belong :-/) My feeling is that figuring out the dependencies should be done in C++. Alex _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
