[CMake] User configuration files for Visual Studio

James Bigler jamesbigler at gmail.com
Thu Jan 12 12:31:45 EST 2012


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/20120112/686259b1/attachment.htm>


More information about the CMake mailing list