On Jan 14, 2008 9:01 AM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > > Brandon Van Every wrote: > > On Jan 13, 2008 10:04 PM, Bill Hoffman <[EMAIL PROTECTED]> wrote: > >> Many people will run CMake from a GUI and will not be giving a > >> -f flag. With the patch there would be no way to build a project via > >> one of the GUI's if it required changing the name of the file. > > > > cmakesetup and ccmake would also need -f flags. Command line users > > and scripts could invoke -f flags just fine. Shortcuts on Windows can > > be made with -f flags in them if people want to present their builds > > that way. > > > >> If you > >> had two or more sets of cmake files in the same source tree, how would > >> that work? > > > > The same way it works now. Generally, such files are a case of "CMake > > invoking CMake." > > > > No offense Brandon, but I would like to here from Martin about how he > plans to use this feature.
I imagine he will get around to answering for himself, but since I have my own case uses, I will explain mine. > I am not sure why you would want to have to > co-existing source trees. Example: I have a legacy handwritten GMake client.mk that acquires the build tree from CVS before the main Autoconf generated Makefile is run. The tree is grabbed from CVS and built by typing "make -f client.mk". The simplest translation to a CMake system would be "cmake -f client.txt". Nobody would be doing a different drill, the client would perceive this as nice, to not have to learn much of anything different. Once the build tree has been acquired, we don't need client.mk anymore. The equivalent of Autoconf's Makefile should always be CMakeLists.txt. This idiom of handwritten GMake files that provide isolated services to a large build tree is endemic to the large codebase I'm working on. "cmake -f weirdfile.txt" is a nice interface for that. Asking people to learn what CML_NAME means, when it isn't documented anywhere, is not a nice interface. I didn't think it would be unreasonable to expect CMake to use the same command line conventions as nearly every other tool out there. Who *doesn't* use -f for file? I'm surprised at the level of resistance you're offering for a minor feature that's standard design in hundreds of tools. > Also, I am not sure the same thing can't be > done with if and include. This requires the user to learn a CMake specific idiom, an example of which is not documented anywhere. Do enough of these inelegant workarounds, requiring people to hunt and peck for the answer, and people will rightly turn away from CMake over syntax issues, just not liking how it works, etc. Comprehensive chapter-oriented documentation can mitigate such problems, but it is better to simply do what everyone else does. > I also > don't see people invoking cmakesetup with any flags, it is a gui > program. Scripts may invoke it on behalf of people. People may invoke it if the README.TXT tells them to do so. As I said, in my current codebase the standard way of pulling the source tree from CVS and starting a build is "make -f client.mk". I think part of the disconnect here, is you're failing to recognize there's a whole breed of hackers out there that lives and dies by the command line. Sure they'll invoke a gui tool. By typing something on the command line. Please just throw the command line guys a bone. All the cool tools are doing it. Cheers, Brandon Van Every _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
