[CMake] User configuration files for Visual Studio

[James Bigler]

On Fri, Jan 20, 2012 at 9:17 AM, Robert Dailey <rcdailey at gmail.com> wrote:

> 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
>>>>
>>>
>>>
>>
>
I think this is a solid approach.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120120/ac0db955/attachment.htm>