> > It would be helpful (at least in my case) to be able to turn off the > > production of the "OutDir" directories in this list, I just haven't > > gotten around to figuring out how. Is there a simple way to control > > this? > > Both directories are always added. This is hard-coded in the VS7 > generator. The reason is that it is not known when the user specifies a > link directory in CMake code whether that directory points directly at a > library or points to another CMake build tree in which there are > per-configuration subdirectories. With the information about link > libraries and directories currently available from CMakeLists.txt files > it is not possible to compute which path is needed.
Actually, in my special case it IS possible to know which path is needed, because the person who originally set up our Visual Studio workspace decided that all the .lib files should be deposited in one directory named "lib", and all the .dll files should be deposited in one directory named "bin". I suppose he was influenced by Unix conventions. This arrangement means that we lose the ability to keep debug and release configurations side by side under one root directory, but one of the wonderful things about CMake is you can do out-of-source builds so that your debug and release configurations are built under different root directories, which seems to work just as well (or better than) the OutDir convention. So the answer is that we simply never use the "OutDir" path for any Library used by this particular workspace, no matter what. It seems to me that in most cases, before the user creates the various CMakeLists.txt files he or she can determine for any given library whether that library will be obtained from a per-configuration "OutDir" directory, or whether that library always comes from the same directory no matter which configuration CMake is told to create. And then the user could flag a library named in TARGET_LINK_LIBRARIES to indicate whether it uses OutDir or not; or perhaps the user could pass these libraries to some other commands that are variants of TARGET_LINK_LIBRARIES. So there's really no burden on CMake to figure out anything about the directory structure; it's merely a matter of providing control to the user through the interface. On the other hand, the main effect of the lack of user control is that a string that you don't often look at anyway is longer than needed. This is something that I hardly ever even notice, not a major drawback. -- David Karr _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
