Another alternative might be to have CMake generate Visual Studio 6 project files, using the variable that controls whether or not CMake rules get added to turn off the re-run CMake rules.... and then use Visual Studio 2008 to convert those project files...?<br>
<br><div>If that is infeasible, I would recommend opening a feature request in the CMake issue tracker at <a href="http://public.kitware.com/Bug">http://public.kitware.com/Bug</a> and attaching a patch to it. Otherwise, it may get lost in the noise of the mailing list.</div>
<div><br></div><div>HTH,</div><div>David Cole</div><div><br></div><div><br><div class="gmail_quote">On Wed, Nov 26, 2008 at 4:54 PM, <span dir="ltr"><<a href="mailto:David.Karr@l-3com.com">David.Karr@l-3com.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The context of this question is that I'm porting an existing project<br>
from Visual Studio 6.0 to Visual Studio 2008. This project has used<br>
CMake for several years, but before that it already had its own file<br>
structure into which it put all the files that it built.<br>
<br>
Specifically, each Visual Studio project had its own subdirectory within<br>
the overall project, like this:<br>
<br>
${my_project_SOURCE_DIR}/project1<br>
${my_project_SOURCE_DIR}/project2<br>
<br>
When building the Debug configuration (for example), most of the output<br>
files (including OBJ, IDB, and PDB files) went into "Debug"<br>
subdirectories, like so:<br>
<br>
${my_project_BINARY_DIR}/project1/Debug<br>
${my_project_BINARY_DIR}/project2/Debug<br>
<br>
But there were several exceptions. The LIB files were all created in<br>
one directory, while the DLL and EXE files were all created in another<br>
directory:<br>
<br>
${my_project_BINARY_DIR}/lib (LIB files)<br>
${my_project_BINARY_DIR}/bin (DLL and EXE files)<br>
<br>
This limits us to building only one configuration per build tree, but<br>
that's quite all right with everyone; you want a different<br>
configuration, you set up a new build tree.<br>
<br>
Several developers who work on this project every day use the Visual<br>
Studio IDE in out-of-source builds for all their work. And they have<br>
various useful options, for example a single STRING definition on the<br>
cmake.exe command line controls whether they get browse info files.<br>
I've also set up CMake so that they can add or remove sources from a<br>
project just by creating or deleting files in that project's directory.<br>
Meanwhile, at least once a day, a very intricate Perl script performs an<br>
in-source build of this project, using the command-line Visual Studio<br>
compiler/linker, always building whatever we have set as the "default"<br>
build configuration; it then installs the result within a much larger<br>
system; and this automated process is maintained by an entirely<br>
different set of personnel on a different network.<br>
<br>
So I have one set of "clients" who visibly benefit from CMake every day,<br>
and another set who get no perceived benefit from CMake at all and would<br>
prefer that the developers just hand over preconfigured DSW and DSP<br>
files as the developers of other projects in the larger system do.<br>
Moreover, I am really in no position to debug the procedure that<br>
incorporates this project's output into the larger system, so I'm<br>
reluctant to have files written to directories other than the<br>
directories where they've always been written; I simply don't know which<br>
changes might break the system build, and every time our group's use of<br>
CMake causes any problem for anyone else, we are pressured to stop using<br>
it.<br>
<br>
<br>
For Visual Studio 6.0, I could get all the files to come out exactly<br>
where I wanted; I added command-line options to CMAKE_CXX_FLAGS, for<br>
example "/implib" and "/out", for part of the necessary output paths,<br>
and created a Templates directory in my project containing modified<br>
copies of some of the files from the CMake Templates directory to take<br>
care of the rest. But the Visual Studio 2008 generator works on a<br>
completely different design that doesn't use templates and that appears<br>
to ignore command-line options such as "/implib" and "/out" (for quite<br>
understandable reasons, since you can no longer just copy these options<br>
into the VS project files). Instead, there is a rigid scheme governing<br>
certain details of the directory structure. For example, the files that<br>
used to be in ${my_project_BINARY_DIR}/project1/Debug are now<br>
distributed between two subdirectories:<br>
<br>
${my_project_BINARY_DIR}/project1/Debug<br>
${my_project_BINARY_DIR}/project1/project1.dir/Debug<br>
<br>
I _guess_ this _probably_ won't break the automated script, and if not,<br>
I might be able to live with it (in fact sometimes it could be<br>
convenient), but the reason why CMake creates project1.dir simply<br>
doesn't exist for our project; our directory names will always follow<br>
the pattern x/x.dir/Debug, _never_ x/y.dir/Debug, so this feature seems<br>
to be a completely unnecessary risk for us.<br>
<br>
Another thing is I've found no way to get CMake to put the LIB and DLL<br>
files into the lib and bin directories. The closest I can get (in the<br>
Debug configuration) is to have the files written to these directories:<br>
<br>
${my_project_BINARY_DIR}/lib/Debug (LIB files)<br>
${my_project_BINARY_DIR}/bin/Debug (DLL and EXE files)<br>
<br>
This seems highly likely to get me into trouble. I can have the files<br>
built into some Debug directory and then copy them to the desired lib<br>
and bin directories in the INSTALL project, but I'm still not 100% sure<br>
I can do this without breaking something in the system build, and even<br>
if it doesn't, someone might complain about the extra copies of the<br>
files.<br>
<br>
It would be ever so much easier for me if CMake just provided a couple<br>
of extra options to say where certain output files got written. For<br>
example, if a SHARED library project were built in the Debug<br>
configuration with the following CMake variables,<br>
<br>
SET(CMAKE_EXPLICIT_OUTPUT_FILE_DIR ${MY_DLL_DIR})<br>
SET(CMAKE_EXPLICIT_IMPORT_LIBRARY_DIR ${MY_LIB_DIR})<br>
<br>
this would be equivalent to setting the command-line options<br>
/out="${MY_DLL_DIR}/project1.dll" and<br>
/implib="${MY_LIB_DIR}/project1.lib" for the Visual Studio linker. (I<br>
suppose it could also cause the Unix makefile to produce<br>
${MY_DLL_DIR}/project1.so and/or ${MY_LIB_DIR}/project1.a when<br>
appropriate.)<br>
<br>
I thought perhaps the property IMPORTED_IMPLIB might do some of what I<br>
want, but I haven't figured out how to use it at all.<br>
<br>
What I actually have implemented (to assist my port to VS 2008) is a<br>
modification of CMake 2.6.2 that supports something like this:<br>
<br>
SET(EXPLICIT_OUTPUT_FILE_NAME ${MY_SHLIB_DIR}/project1${SHLIB_EXT})<br>
SET(EXPLICIT_IMPORT_LIBRARY_NAME ${MY_LIB_DIR}/project1${LIB_EXT})<br>
<br>
In other words, I can hack one or two classes in the CMake source to do<br>
everything I want, and I can probably get away with this, since the<br>
people who run the build script will just use whatever copy of cmake.exe<br>
I hand to them. But I would prefer to use existing CMake functionality<br>
if it exists; and if it doesn't, I wonder if it would be worth adding<br>
this functionality as an option to CMake. (My hacked version actually<br>
acts exactly like CMake 2.6.2 if you don't use any of the three or four<br>
new variables I defined.)<br>
<br>
David Karr<br>
<br>
<br>
_______________________________________________<br>
CMake mailing list<br>
<a href="mailto:CMake@cmake.org">CMake@cmake.org</a><br>
<a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div><br></div>