[CMake] User configuration files for Visual Studio

[Robert Dailey]

Any thoughts on this guys? Here are my ideas for this:

For VS8 and VS9:

CMake will only generate the my_project.vcproj.user files. Visual Studio
will NOT use these unless you delete your *other* user file, which is in
the format of: my_project.vcproj.COMPUTER.USER.user. If the user wishes to
have the generated values, they must delete the machine-specific user file,
and reload visual studio, at which point it will use the
my_project.vcproj.user file as a source for defaults, and then it will
generate the my_project.vcproj.COMPUTER.USER.user file with those values.

For VS10 (and not sure about VS11):

Since Visual Studio does not generate a secondary .user file like it did in
VS8 and VS9, CMake should ONLY generate the user file if one does not exist
already. The first time generation happens, obviously they will not exist
so they will be generated. Everytime thereafter it will not generate them.
If the user wishes to get new values, they need to delete their
my_project.vcproj.user file.

To aid in deleting the vcproj files for each appropriate version of Visual
Studio, you could automate this in your CMake scripts. You could
recursively delete all *user files, or you could delete only a select few
based on how user file information is updated. Since the circumstances
under which the user files will be edited, deleted, updated, and so forth,
are different between users, CMake shouldn't do anything to facilitate
this, but instead allow enough flexibility in the scripts to let the users
implement these details.

How does my idea sound? It lets you generate these files without replacing
custom user-edits made through visual studio, or even by hand.

---------
Robert Dailey


On Thu, Jan 12, 2012 at 11:31 AM, James Bigler <jamesbigler at gmail.com>wrote:

> I would be fine with that if the generation of these files would only
> happen if either they weren't present or you manually forced them to be
> created.  Folks are just used to modifying them in the VS IDE, and it would
> be too easy for users to make a change in the IDE and then have CMake
> overwrite them on a configure.  Plus the project reloading in VS is really
> slow.
>
> James
>
>
> On Thu, Jan 12, 2012 at 10:17 AM, Robert Dailey <rcdailey at gmail.com>wrote:
>
>> Or you could just change the properties as normal in the VS options
>> dialog, until you find settings that work and you want to keep. Then update
>> the cache variables or whatnot in CMake, so next time you generate you will
>> have them.
>>
>> There is nothing preventing you from using the normal method of changing
>> debug parameters.
>>
>> ---------
>> Robert Dailey
>>
>>
>>
>> On Wed, Jan 11, 2012 at 5:53 PM, James Bigler <jamesbigler at gmail.com>wrote:
>>
>>> On Wed, Jan 11, 2012 at 8: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.
>>>>
>>>>
>>> I would be vehemently against any idea that would *require* me to edit
>>> any file to change debug parameters.  This is an integral part of how VS
>>> should be used.  The time for an iteration cycle and annoyance of this
>>> would be too high for most developers.
>>>
>>> 1. Edit paramfile
>>> 2. Configure with CMake
>>> 3. Wait for VS to recognize the file has changed or the slow slow CMake
>>> VS plugin to figure out what is going on and ask me to reload the file.
>>> 4. Run my code
>>> 5. Decide I need to change another debug parameter
>>> 6. Rinse and repeat until I decide to pull my hair out
>>>
>>> I would not be opposed for a default version of the file or the option
>>> to overwrite the existing ones, but once it has been created please leave
>>> it alone and let me configure it through the GUI.
>>>
>>> James
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120120/a7d444bc/attachment.htm>