[CMake] User configuration files for Visual Studio

[Robert Dailey]

For VS8-VS9, this won't be a big issue since Visual Studio does not use the
.user file directly, instead it copies it and creates a DOMAIN.USER.user
file instead. For VS10, however, it does not do this, so when we edit the
.user file it will use that file directly. I think VS10 is the only version
that will be of concern to your point.

I think instead of adding this to the target properties function, we should
add a new function for this, for several reasons:

1) There are a ton of properties one can set in the USER file. These would
only add to the already-cluttered target properties list.
2) Since these are all VS specific, adding a new command will be easier to
track the MS IDE specific properties.
3) If we add them to set_target_properties, we'll need to use some strange
naming convention to make it obvious that these are not portable. For
example: VS_DEBUG_USER_COMMAND_PARAMETERS. Whereas if we have a
"set_user_properties" command, we can give them cleaner names like
COMMAND_PARAMETERS, ENVIRONMENT_VARIABLES, WORKING_DIRECTORY, and so forth.

Example:

set_user_properties( target_name PROPERTIES COMMAND_PARAMETERS "-debug
-reg" ENVIRONMENT_VARIABLES="${path};INSTALL_DIR=${installdir}" )

When generating for anything that isn't the VS IDE, or doesn't have a
similar, translatable concept, this function will be a no-op.

---------
Robert Dailey


On Wed, Jan 11, 2012 at 9:41 AM, David Cole <david.cole at kitware.com> wrote:

> I'm sure there are a handful of interested parties on this topic.
>
> One concern I would have is that if we start to generate this, we
> might clobber stuff that users go in and edit by hand in the Visual
> Studio UI. It's a minor concern, but if I do go in and add a
> "PATH=1;2;3;4" to the environment, then I wouldn't want CMake to
> clobber it. I could get used to editing a CMake file or a
> configuration .in file for such settings though...
>
> It's a reasonable idea.
>
>
> On Wed, Jan 11, 2012 at 9:54 AM, Robert Dailey <rcdailey at gmail.com> wrote:
> > I guess I have failed to strike the interest of anyone on this?
> >
> > ---------
> > Robert Dailey
> >
> >
> >
> > On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey <rcdailey at gmail.com>
> wrote:
> >>
> >> 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
> >
> >
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120111/cb78c98c/attachment-0001.htm>