On Tuesday 15 January 2008 16:40, you wrote: > Martin Lutken wrote: > > That might work too. > > I also does not understand why You are soo resistant to a minor feature > > which couldn't really hurt anyone? > > I just want to make sure it is a feature that we want. I will be one of > the ones supporting it for as long as CMake is around. As it is your > patch has some issues. For example, if you changed a CMakeLists.txt > file, and ran make on the build tree, it would fail as it is. This is > because the command to rerun cmake would also need to have the -f flag > as well, and does not. Of course, that can be fixed. > > So, I guess the process for getting stuff into CMake should be stated > somewhere. So, here it is: > > 1. Have the idea approved on the cmake mailing list. Basically get buy > in from the CMake community and developers for the feature. > > 2. Create a bug / feature request in the bug tracker. > > 3. Submit a patch to the bug tracker, complete with a test case that has > good coverage on the new code being added. > > (3 is optional, but should speed things up. If it is a must have > feature, then the cmake developers will eventually get around to adding > it. However, it it is a solid well tested patch, it will more more > likely to be added as-is.) > > My concerns for this feature are as follows: > > It will confuse users of CMake. They will download a project and have > to use extra command line arguments to get things to work. If they just > run CMakeSetup, cmake, or ccmake as stated in the usual CMake > documentation it will not work. Basically, I think it may make cmake > based builds harder to understand and support. > > I would think that the existence of two complete cmake build systems in > any one source tree, would be one two many. It is hard enough to > maintain one build system, much less two flavors of cmake. Seems like > something that would only be used as a temporary stop gap. The new > build stuff would either be accepted or rejected by the project, and the > co-existing stuff would go away. For a temporary thing, it could be > done with includes, and parallel source trees. > > I don't mean to offend, and I appreciate your use and extensions to > CMake, and look forward to your future contributions. > > -Bill
Hmm well I see .... It can wait anyway. I allready do the include-trick from the general Makefile, but in the transitional phase for a large project it would be much easier to be able do it that way. Maybe it's because I never really used CMake GUI frontends.... Only tried them briefly. Since I am trying to construct a system in which you can build and configure many (possibly a complete Linux Distribution) in one build, while still workinbg perfectly for the individual subprojects I have neeeds which are a bit special .... But I might add the request to the feature request list... -Martin _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake