<div>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.</div>
<div><br></div><div>I think instead of adding this to the target properties function, we should add a new function for this, for several reasons:</div><div><br></div><div>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.</div>
<div>2) Since these are all VS specific, adding a new command will be easier to track the MS IDE specific properties.</div><div>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.</div>
<div><br></div><div>Example:</div><div><br></div><div>set_user_properties( target_name PROPERTIES COMMAND_PARAMETERS "-debug -reg" ENVIRONMENT_VARIABLES="${path};INSTALL_DIR=${installdir}" )</div><div>
<br></div><div>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.<br clear="all"><div><br></div><div>---------</div>Robert Dailey<br>
<br><br><div class="gmail_quote">On Wed, Jan 11, 2012 at 9:41 AM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sure there are a handful of interested parties on this topic.<br>
<br>
One concern I would have is that if we start to generate this, we<br>
might clobber stuff that users go in and edit by hand in the Visual<br>
Studio UI. It's a minor concern, but if I do go in and add a<br>
"PATH=1;2;3;4" to the environment, then I wouldn't want CMake to<br>
clobber it. I could get used to editing a CMake file or a<br>
configuration .in file for such settings though...<br>
<br>
It's a reasonable idea.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Wed, Jan 11, 2012 at 9:54 AM, Robert Dailey <<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>> wrote:<br>
> I guess I have failed to strike the interest of anyone on this?<br>
><br>
> ---------<br>
> Robert Dailey<br>
><br>
><br>
><br>
> On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey <<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>> wrote:<br>
>><br>
>> there are .user files generated by newer versions of Visual Studio (since<br>
>> 2005 I believe) that contain per-machine or per-workspace information. For<br>
>> all intents and purposes these are temporary files that are not checked into<br>
>> version control.<br>
>><br>
>> The normal file naming convention for these are:<br>
>><br>
>> project.vcproj.DOMAIN.USER.user<br>
>><br>
>> Where DOMAIN is the machine/domain name, and USER is the local account<br>
>> name.<br>
>><br>
>> I found out a couple of years ago that if you rename it to this:<br>
>><br>
>> project.vcproj.user<br>
>><br>
>> Visual Studio will treat this as "defaults" for the machine-specific<br>
>> version created using the naming convention I first outlined.<br>
>><br>
>> The user files are useful for setting debug working directory and command<br>
>> arguments. There are some other things you can set but I have never found a<br>
>> use for them. Since I like to set these two parameters, what I've done is<br>
>> keep my template user file in version control, and use CMake's<br>
>> configure_file() to fill in the command arguments and working directory<br>
>> fields for me. This approach is a good workaround but I'd really like to see<br>
>> CMake generate these for me. Right now I have to keep 1 user file for each<br>
>> version of visual studio that can be used, and configure them differently<br>
>> based on VS IDE selection.<br>
>><br>
>> Would it be suitable for CMake to incorporate this functionality? If CMake<br>
>> provided built-in support for this, we could create target properties that<br>
>> would set these fields on the target (it would set them on the generated<br>
>> user file instead of the vcproj file like normal target properties would<br>
>> do):<br>
>><br>
>> set_target_properties( project PROPERTIES<br>
>> DEBUG_COMMAND_ARGUMENTS "-debug -reg"<br>
>> DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"<br>
>> )<br>
>><br>
>> I'd be happy to help implement this should David, Bill, and others find it<br>
>> to be a good idea.<br>
>><br>
>> PS: I think I can do it without boost this time ;)<br>
>><br>
>> ---------<br>
>> Robert Dailey<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> --<br>
><br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the CMake FAQ at:<br>
> <a href="http://www.cmake.org/Wiki/CMake_FAQ" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.cmake.org/mailman/listinfo/cmake" target="_blank">http://www.cmake.org/mailman/listinfo/cmake</a><br>
</div></div></blockquote></div><br></div>