[CMake] User configuration files for Visual Studio

[Robert Dailey]

there are .user files generated by newer versions of Visual Studio (since
2005 I believe) that contain per-machine or per-workspace information. For
all intents and purposes these are temporary files that are not checked
into version control.

The normal file naming convention for these are:

project.vcproj.DOMAIN.USER.user

Where DOMAIN is the machine/domain name, and USER is the local account name.

I found out a couple of years ago that if you rename it to this:

project.vcproj.user

Visual Studio will treat this as "defaults" for the machine-specific
version created using the naming convention I first outlined.

The user files are useful for setting debug working directory and command
arguments. There are some other things you can set but I have never found a
use for them. Since I like to set these two parameters, what I've done is
keep my template user file in version control, and use CMake's
configure_file() to fill in the command arguments and working directory
fields for me. This approach is a good workaround but I'd really like to
see CMake generate these for me. Right now I have to keep 1 user file for
each version of visual studio that can be used, and configure them
differently based on VS IDE selection.

Would it be suitable for CMake to incorporate this functionality? If CMake
provided built-in support for this, we could create target properties that
would set these fields on the target (it would set them on the generated
user file instead of the vcproj file like normal target properties would
do):

set_target_properties( project PROPERTIES
   DEBUG_COMMAND_ARGUMENTS "-debug -reg"
   DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
)

I'd be happy to help implement this should David, Bill, and others find it
to be a good idea.

PS: I think I can do it without boost this time ;)

---------
Robert Dailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120109/32c12aae/attachment.htm>