On Fri, Jan 20, 2012 at 9:17 AM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey@gmail.com">rcdailey@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any thoughts on this guys? Here are my ideas for this:<div><br></div><div>For VS8 and VS9:</div><div><br></div><div>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.</div>
<div><br></div><div>For VS10 (and not sure about VS11):</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><div><br></div><div>How does my idea sound? It lets you generate these files without replacing custom user-edits made through visual studio, or even by hand.</div><div><br></div><div>---------</div><span class="HOEnZb"><font color="#888888">Robert Dailey</font></span><div>
<div class="h5"><br>
<br><br><div class="gmail_quote">On Thu, Jan 12, 2012 at 11:31 AM, James Bigler <span dir="ltr"><<a href="mailto:jamesbigler@gmail.com" target="_blank">jamesbigler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<span><font color="#888888"><br>
<br>James</font></span><div><div><br><br><div class="gmail_quote">On Thu, Jan 12, 2012 at 10:17 AM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey@gmail.com" target="_blank">rcdailey@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<div>
<br></div><div>There is nothing preventing you from using the normal method of changing debug parameters.<br clear="all"><div><br></div><div>---------</div><span><font color="#888888">Robert Dailey</font></span><div>
<div><br>
<br><br><div class="gmail_quote">On Wed, Jan 11, 2012 at 5:53 PM, James Bigler <span dir="ltr"><<a href="mailto:jamesbigler@gmail.com" target="_blank">jamesbigler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Jan 11, 2012 at 8:41 AM, David Cole <span dir="ltr"><<a href="mailto:david.cole@kitware.com" target="_blank">david.cole@kitware.com</a>></span> wrote:<br></div><div><div class="gmail_quote">
<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><div><br></div></div></blockquote></div><br></div>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.<br><br>1. Edit paramfile<br>2. Configure with CMake<br>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.<br>
4. Run my code<br>5. Decide I need to change another debug parameter<br>6. Rinse and repeat until I decide to pull my hair out<br>
<br>
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.<span><font color="#888888"><br><br>James<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br>I think this is a solid approach.<br><br>James<br>