[CMake] VisualStudio 7.1 projects

[Dekeyser, Kris]

>    Actually, I thought there might be an option that directly maps
> into VS's IntermediateDirectory and OutputDirectory project settings.
> 

It's a pitty, but I'm afraid there is none. At least not for VS6. The
Intermediate and Output dirs are relative to the CMAKE_CURRENT_BINARY_DIR
and to my knowledge you cannot changed them. I would recommend to add that
to the wishlist. We have been playing with those settings when we were still
updating our VS6 projects by hand and it turned out to be very handy. But we
learned to live without it in favor of the features of CMake. ;-)

> DK> - Yes, we had the exactly the same problem. For link 
> libraries, CMake
> DK> provides the debug/optimized option to 
> TARGET_LINK_LIBRARIES and that works
> DK> fine. Unfortunately there is no such option for 
> LINK_DIRECTORIES and
> DK> INCLUDE_DIRECTORIES. You can solve the LINK_DIRECTORIES 
> problem by adding
> DK> the full path to the library name in 
> TARGET_LINK_LIBRARIES. I could not find
> DK> any way to solve the INCLUDE_DIRECTORIES problem than to 
> create single-build
> DK> MsDev projects. I have added a FAQ for this to the CMake 
> Wiki pages. It's
> DK> for VS6 and requires some effort. For VS7 it should be as 
> easy as setting
> DK> the CMAKE_CONFIGURATION_TYPES to a single 
> value(Debug/Release/...). This
> DK> means that you will have a separate build tree for each 
> single configuration
> DK> type - exactly like what you would do with Makefile based builds.
> 
>   If I understand correctly, this means that I would have a different
> workspace (or VS 7 solution) for each configuration?

Yes, that's what we do now for our build system. In our case, that's not
much of a problem. Developers normally only build in debug mode and our
central build server only builds release versions. Support people only need
DebugRelease versions, etc. Since we're developing both on Windows and Unix
we're used to the single config makefiles anyway.

If you do an in-source build that solution may not be very handy, but we
typically create a subdir like "App_6A_Debug" and create our single config
build tree there. I have done some testing with three different build trees
and there is harly any disk space overhead compared to one multiple config
build tree. IMHO single config build trees are cleaner and we eliminated one
anoying side-effect of CMake: when a workspace is open and the
CMakeLists.txt was updated and causes workspaces to be updated in VS, VS
often switched from Debug to Release after updating the workspaces.

>   
> DK> - ADD_DEPENDENCIES should only be used for exceptions. Use
> DK> TARGET_LINK_LIBRARIES instead.
> 
>   Yes, this does work, however it does not add a VS dependency to the
> workspace (solution).

Hmm, that sounds like a bug, because what I see in VS6 is a project
dependency for each TARGET_LINK_LIBRARIES added. Maybe you need some extra
setting for VS7? I do not have VS7 available (yet), so it's hard to tell.
But one thing I know for sure: it SHOULD work. Are you sure the both
projects are defined when you issue the TARGET_LINK_LIBRARIES command? We
had some problems earlier on due to the wrong order of SUBDIRS commands in a
parent directory. The dependency projects should be included (loaded) before
the dependent project. CMake may not issue much of a warning when you got
the order wrong.

> 
>   Thanks for your help,
>      Bojan Resnik
> 
> 

You're welcome ;-)

- Kris

BTW I'm not affiliated or related to the CMake team and I'm still learning
new CMake features every day myself. I may very well be completely wrong in
my analysis.
+-+-+- Email Confidentiality Footer +-+-+- 
Privileged/Confidential Information may be contained in this message. If you
are not the addressee indicated in this message (or responsible for delivery
of the message to such person), you may not print, retain, copy nor
disseminate this message or any part of it to anyone and you should notify
the sender by reply email and destroy this message. Neglecting this clause
could be a breach of confidence. Please advise immediately if you or your
employer does not consent to Internet email for messages of this kind.
Opinions, conclusions and other information in this message that are not
related to the official business of my firm shall be understood as neither
given nor endorsed by it.