At 04:05 AM 5/30/2006, Thomas Zander wrote: >Maybe a little change in approach will solve some hard-to-crack issues. >If the project manager just runs 'cmake --create-configure' after he made >some changes in the build system, which in turn will generate a configure >script with the projects options then you can put that generated file in >the project svn and the distributed tarballs. > >This sticks better with the concept of CMake which is a generator and it >sidesteps ugliness of having one script that should work for everyone. > >When you take that approach then you can think about how to expose >features to the configure script at script-generation time. This can >range from options passed to adding a command in the CMakeLists.txt like >'expose FOO_BAR "foo bar" [toggle|string]' >--
I don't think we want to generate a configure script since it will only run on systems with a unix shell. However, I like the idea of making the command line to cmake configurable. I think we all agree that avoiding cmake -DSOME_REALLY_LONG_CAP_NAME=/some/path is a good thing. The question now, is what is the best way to provide better, configurable options to cmake. I think some file in the projects top level directory would not be a bad idea. It would be easy to implement, (no extra pass that only parses.) It would be up to the project maintainer to make sure it was reflected in the variables of the project. We could also have a default one that could be included to give a standard set of options like --prefix. -Bill _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake