On Fri, Jan 20, 2012 at 9:17 AM, Robert Dailey <rcdai...@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 <jamesbig...@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 <rcdai...@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 <jamesbig...@gmail.com>wrote: >>> >>>> On Wed, Jan 11, 2012 at 8:41 AM, David Cole <david.c...@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
-- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake