> [email protected] wrote: > > Brad King wrote: > >> Perhaps the install() command is better for that. > > > > it adds an extra step into the procedure > > Just run "make install" instead of "make".
If they used make. But yes, I suppose we could have an Install "project" in Visual Studio. That would still force a difficult negotiation with my customer, who still has an unresolved software defect report on file asking why my group of developers is using CMake instead of just checking sln and vcproj files into ClearCase like all their other developer groups are. The resolution I'd like to reach for that software defect report is to have all the other developer groups also use CMake so that my group will no longer be the odd one out. But to reach that resolution, I have to sell the idea of CMake to a lot of people. Even to reach the second best outcome--where the other groups don't use CMake, but they stop complaining about the fact that my group does--looks like it will require a major sales pitch at some point. This whole project (my group's part and all the others) has run for a long time already, and it has been using Visual Studio files that have done basically the same thing in the same way, putting the same kinds of files in the same places, for quite a number of years (I'd guess more than 8 years, though I'd have to look back carefully to be sure), with a new distribution prepared every night and frequent installations in various locations. As far as most of the people involved are concerned, the build process for all the parts of the software that don't use CMake are fine the way they are. Every time someone notices that CMake insists on doing something a different way, even if the new way is perfectly logical and reasonable, it's one more reason to complain to me. I think CMake would solve a lot of headaches that the rest of the group has suffered due to their reliance on moldy old Visual Studio project files (for example, immense hacking of their vcproj files so they cou ld do concurrent development in two versions of the compiler, which they could much more easily have solved by using out-of-source builds). But to put this across, I first need people to listen to what CMake can do for them that their current system can't, and it's hard to get them to listen to that when they're focusing on all the things their current build does "easily" that we can't get CMake to do in exactly the same way. If it were just me messing around with some solo software development, or even just me telling all the developers in my own group that this is the way we're going to manage our builds, I'd be a lot more eager to see if I can use install() to do just what I really need to do (not necessarily exactly what the people around me and I have been doing all along). Even within the larger group of developers, I don't suppose the install() issue by itself would be a deal-breaker. But it's that and all the other similar constraints of CMake that make me concerned I won't be able to "sell" it--and if I don't make the sale I may lose the choice to use it at all. > The install() command was designed to give precise control over > the construction of install trees (AKA stages before tarballing). > I see no strong need to duplicate this functionality to the same > level of precision for the build outputs. There's no need from the perspective of someone who just wants a clear, logical build system. CMake provides one. The problem comes when you want CMake to replace an existing build system around which a large group of developers have already built up resistance to change. I suspect that a lot of the inquiries on the CMake mailing list, and even a lot of the features already in CMake (perhaps even the CMAKE_RUNTIME_OUTPUT_DIRECTORY_* variables, where we started this discussion) are due to the preconceived notions that certain groups of developers already corporately assume about their build procedures, and the need to overcome the inertia of those preconceived notions. By the way, this level of control long ago existed and (AFAIK) still exists for anyone building a Visual Studio 6.0 project in CMake. You can do most of what you need by adding command-line options to variables such as CMAKE_CXX_FLAGS and CMAKE_EXE_LINKER_FLAGS (with SET commands guarded by IF commands so you don't pass these options to other compilers!), and you could do the rest of it by directing the VS 6.0 generator to get its templates from a directory specific to your particular project. I very much sympathize with your aversion to re-introducing all this fine-grained control, if we assume that the only way to do it is to continue down the current path of adding all these little onesie-twosie variables properties literally programmed ad-hoc into the CMake C++ source code in order to tweak this detail and that detail of the build. Just trying to learn to use all these independent features is hard enough--programming and maintaining them is surely worse. I would very much more like to see a return to the idea that if the user of CMake wants to tweak all these little things in his or her build--especially when they're like a lot of the details of the Visual Studio build, minutiae that have no true counterpart in most other compilers--then the user of CMake can add the appropriate command-line options (via CMAKE_CXX_FLAGS and other variables) for the particular build system that is to be tweaked, and make modified copies of template files to tweak some things t hat can't be tweaked on the command line. The command-line-and-templates alternative (as implemented in the VS 6 generator) had at least three major benefits. One is that the CMake C++ source code is free from all these vendor-specific details, which makes CMake itself more maintainable. A second benefit is that you have a nice way to tell users of CMake not to bother you with requests for these tweaks--you can tell them to do it themselves. A third benefit is that users have a viable alternative to the current choices: waiting and hoping you'll put their feature in CMake, hacking the CMake code themselves, or doing without. Granted, command lines and templates never addressed all the differences between CMake-generated build files and whatever people were using before, but at least they cleared a bunch of stuff out of the way. Granted, command-line options are often specific to just one compiler implementation, and templates even more so--but the things they would control also tend to be specific to a compiler implementation. Also granted, some kinds of build files (such as VS 7/8/9 vcproj files) are harder to capture in templates than other kinds (such as VS 6 dsp files). But it seems to me worth thinking about for the long term. David _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
