Thomas Zander wrote:Its because it slows me down a lot. When I change a couple of header files I suddenly see it reconfiguring for no apparent reason. Its when I type 'make' it takes upto a minute before it actually starts with the first gcc, even if I typed make moments before. (I just typed 'make | less' this time). I saw your other post about massive slowdowns. I haven't experienced that sort of thing myself, but Chicken is a small project so it's not likely I would. Best to keep that issue separate in its own thread. Its that there is no feedback on what I am doing wrong when I alter the CMakeLists.txt file, When I type something wrong in CMakeLists.txt, and then I run CMakeSetup or CCMake again, I get dialog boxes telling me there's some error on such-and-such a line. The errors have usually been helpful, if not always. that combined with the 5 minutes it takes between edit and output me frustrated when I need to add something. At times I have wanted file-level dependency targets for this reason. I don't find myself inconvenienced if I'm building a main target, like "make silex." Incidentally, my typical debugging technique is to look at the generated Makefiles to see what's wrong with them. Usually there's a path qualification error. Usually it's my error; sometimes I've found a bona fide CMake bug. I consider the freely available documentation to be weak. Meaning, it's not integrated, it's scattered across official documentation, the FAQ, and the wiki. The $$ documentation might be better, I don't know. The free help on this list is second to none, which is why I became a CMake pundit. CMake may have problems, but the CMake team is really good at providing solutions. I'd work on improving the CMake documentation myself, but my time is currently limited and what little I have goes towards improving the Chicken build.Its the constant looking for words like VERBOSE=1 which are not easy to find.
Not my universe. --projecthelp may be a commonplace in Javaland, but CMake is C/C++ land for the most part. I doubt that Ant conventions are familiar to this crowd. Familiarity with ./configure conventions are far more likely. CMake is designed to be a ./configure replacement, in the sense that it does the same jobs and does a much better job at cross-platform than ./configure does. When seeking converts, "How does ./configure do it?" is more apropos than "How does Ant do it." I think it's a good idea, I just don't know that it should be called --projecthelp. --targets seems a lot more logical to me. Also, "cmake --help" should list the "--targets" command. That way, people find information in a workflow that they're used to. If CMakeSetup had a menu option to display the targets, that would be useful. Incidentally, you can use graphviz to generate a graph of all the top-level targets. It won't show file-level dependencies though, and it's not a great interface for just getting in there on the command line. Very useful when you're at the head-scratching stage of your project though, and you need to mull over all your dependencies at once.
Any toplevel target has the same name as in CMakeLists.txt, i.e. ADD_EXECUTABLE(chicken ${sourcefiles}) means you can type "make chicken". ADD_LIBRARY(libchicken SHARED ${sourcefiles}) means you can type "libchicken". You could also find out by inspecting the generated Makefiles. What I'm saying is, I don't want the CMake team to waste their time trying to chase ./configure's tail. I'm not interested in converting scripts. Myself, I'm interested in converting *people*. The Right Thing To Do is to drop ./configure entirely. I believe someone has some aides de porte floating around, but you have to understand a lot of stuff to do a conversion from ./configure to CMake. I just don't see the point in trying to automate it, since it's all going to break anyways, and it's a huge task for no payoff.
I instigated the CMake-Promote mailing list. I think ./configure is junk and I'm not interested in mollycoddling their habits beyond the superficial and easily doable. Typing "cmake --help" is a good idea. Automagically allowing them to not learn anything about CMake is stupid. It'll never work, and it doesn't improve CMake's technology or support. The leverage is, you wants real cross-platform build support, then you learns some CMake. There is a price to pay. ./configure can't do the job. If it could, nobody would learn anything else, CMake wouldn't exist. But it does exist, because the GNU Project actively hates Microsoft and is deliberately unwilling to make it easy to use VC++ in their toolchain. I've offered to collect up the sources from 2 VC++ front-ends to make it usable from autoconf. They said, "Please go away. It harms the GNU Project." The advantage of CMake is it doesn't have GNU politics, as much as anything else. You indeed misunderstood me. The question is simply; why rely on make. (gmake or whatever). Why not have a command that I type every time I want to start a build which has nice commandline options and nice output specifically made for cmake. Because CMake is a build system generator, not a build system. It generates *NATIVE* build systems, in many flavors. It's up to you to use your native build system properly after it is generated. It's beyond the scope of CMake to be a one stop interface for every build system imaginable. As it stands, it does an awfully good job of generating consistent behavior across build systems. For instance, in VC++ it produces an INSTALL project. I click on that and hey voila, things install in Unixy fashion. Even though most Windows developers don't do that and create their own installer programs. The problem with the use-(g)make decision is that you are stuck with using unintuitive variable names to alter the build process. Then dump it and develop with VC++. Or some other compiler with a better (or just different ;-) *NATIVE* build system. I mean really, if you don't like gmake, how is that CMake's problem? I think what you're really saying is you like Ant and you want things to be like you already know. Meanwhile, huge numbers of people using GCC also use gmake, or their own kind of system-specific make. As an Ant developer you might find any "make" repugnant, and probably rightly so. But can your Ant generate Makefiles and native VC++ .sln files? CMake can. Cheers, Brandon Van Every |
_______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
