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.c...@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 <rcdai...@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 <rcdai...@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 >
-- 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