Re: [CMake] User configuration files for Visual Studio
On Fri, Jan 20, 2012 at 9:17 AM, Robert Dailey 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 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 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 wrote: >>> On Wed, Jan 11, 2012 at 8:41 AM, David Cole 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
Re: [CMake] User configuration files for Visual Studio
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 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 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 wrote: >> >>> On Wed, Jan 11, 2012 at 8:41 AM, David Cole 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 >>> >> >> > -- 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
Re: [CMake] User configuration files for Visual Studio
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 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 wrote: > >> On Wed, Jan 11, 2012 at 8:41 AM, David Cole 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 >> > > -- 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
Re: [CMake] User configuration files for Visual Studio
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 wrote: > On Wed, Jan 11, 2012 at 8:41 AM, David Cole 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 > -- 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
Re: [CMake] User configuration files for Visual Studio
On Wed, Jan 11, 2012 at 8:41 AM, David Cole 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 -- 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
Re: [CMake] User configuration files for Visual Studio
For VS8-VS9, this won't be a big issue since Visual Studio does not use the
.user file directly, instead it copies it and creates a DOMAIN.USER.user
file instead. For VS10, however, it does not do this, so when we edit the
.user file it will use that file directly. I think VS10 is the only version
that will be of concern to your point.
I think instead of adding this to the target properties function, we should
add a new function for this, for several reasons:
1) There are a ton of properties one can set in the USER file. These would
only add to the already-cluttered target properties list.
2) Since these are all VS specific, adding a new command will be easier to
track the MS IDE specific properties.
3) If we add them to set_target_properties, we'll need to use some strange
naming convention to make it obvious that these are not portable. For
example: VS_DEBUG_USER_COMMAND_PARAMETERS. Whereas if we have a
"set_user_properties" command, we can give them cleaner names like
COMMAND_PARAMETERS, ENVIRONMENT_VARIABLES, WORKING_DIRECTORY, and so forth.
Example:
set_user_properties( target_name PROPERTIES COMMAND_PARAMETERS "-debug
-reg" ENVIRONMENT_VARIABLES="${path};INSTALL_DIR=${installdir}" )
When generating for anything that isn't the VS IDE, or doesn't have a
similar, translatable concept, this function will be a no-op.
-
Robert Dailey
On Wed, Jan 11, 2012 at 9:41 AM, David Cole 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.
>
>
> On Wed, Jan 11, 2012 at 9:54 AM, Robert Dailey wrote:
> > I guess I have failed to strike the interest of anyone on this?
> >
> > -
> > Robert Dailey
> >
> >
> >
> > On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey
> wrote:
> >>
> >> there are .user files generated by newer versions of Visual Studio
> (since
> >> 2005 I believe) that contain per-machine or per-workspace information.
> For
> >> all intents and purposes these are temporary files that are not checked
> into
> >> version control.
> >>
> >> The normal file naming convention for these are:
> >>
> >> project.vcproj.DOMAIN.USER.user
> >>
> >> Where DOMAIN is the machine/domain name, and USER is the local account
> >> name.
> >>
> >> I found out a couple of years ago that if you rename it to this:
> >>
> >> project.vcproj.user
> >>
> >> Visual Studio will treat this as "defaults" for the machine-specific
> >> version created using the naming convention I first outlined.
> >>
> >> The user files are useful for setting debug working directory and
> command
> >> arguments. There are some other things you can set but I have never
> found a
> >> use for them. Since I like to set these two parameters, what I've done
> is
> >> keep my template user file in version control, and use CMake's
> >> configure_file() to fill in the command arguments and working directory
> >> fields for me. This approach is a good workaround but I'd really like
> to see
> >> CMake generate these for me. Right now I have to keep 1 user file for
> each
> >> version of visual studio that can be used, and configure them
> differently
> >> based on VS IDE selection.
> >>
> >> Would it be suitable for CMake to incorporate this functionality? If
> CMake
> >> provided built-in support for this, we could create target properties
> that
> >> would set these fields on the target (it would set them on the generated
> >> user file instead of the vcproj file like normal target properties would
> >> do):
> >>
> >> set_target_properties( project PROPERTIES
> >>DEBUG_COMMAND_ARGUMENTS "-debug -reg"
> >>DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
> >> )
> >>
> >> I'd be happy to help implement this should David, Bill, and others find
> it
> >> to be a good idea.
> >>
> >> PS: I think I can do it without boost this time ;)
> >>
> >> -
> >> Robert Dailey
> >
> >
> >
> > --
> >
> > 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
>
--
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
Re: [CMake] User configuration files for Visual Studio
In light of the current topic about copying 3rd Party DLLs into the build
directory on Visual Studio one suggestion was to create this type of file. With
that in mind I am now interested in this feature. Would make a nice addition
and help those of us who do 32/64 dev all on the same machine where we can not
set global paths.
Thanks
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net www.bluequartz.net
On Jan 11, 2012, at 9:54 AM, Robert Dailey wrote:
> I guess I have failed to strike the interest of anyone on this?
>
> -
> Robert Dailey
>
>
> On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey wrote:
> there are .user files generated by newer versions of Visual Studio (since
> 2005 I believe) that contain per-machine or per-workspace information. For
> all intents and purposes these are temporary files that are not checked into
> version control.
>
> The normal file naming convention for these are:
>
> project.vcproj.DOMAIN.USER.user
>
> Where DOMAIN is the machine/domain name, and USER is the local account name.
>
> I found out a couple of years ago that if you rename it to this:
>
> project.vcproj.user
>
> Visual Studio will treat this as "defaults" for the machine-specific version
> created using the naming convention I first outlined.
>
> The user files are useful for setting debug working directory and command
> arguments. There are some other things you can set but I have never found a
> use for them. Since I like to set these two parameters, what I've done is
> keep my template user file in version control, and use CMake's
> configure_file() to fill in the command arguments and working directory
> fields for me. This approach is a good workaround but I'd really like to see
> CMake generate these for me. Right now I have to keep 1 user file for each
> version of visual studio that can be used, and configure them differently
> based on VS IDE selection.
>
> Would it be suitable for CMake to incorporate this functionality? If CMake
> provided built-in support for this, we could create target properties that
> would set these fields on the target (it would set them on the generated user
> file instead of the vcproj file like normal target properties would do):
>
> set_target_properties( project PROPERTIES
>DEBUG_COMMAND_ARGUMENTS "-debug -reg"
>DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
> )
>
> I'd be happy to help implement this should David, Bill, and others find it to
> be a good idea.
>
> PS: I think I can do it without boost this time ;)
>
> -
> Robert Dailey
>
> --
>
> 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
--
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
Re: [CMake] User configuration files for Visual Studio
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.
On Wed, Jan 11, 2012 at 9:54 AM, Robert Dailey wrote:
> I guess I have failed to strike the interest of anyone on this?
>
> -
> Robert Dailey
>
>
>
> On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey wrote:
>>
>> there are .user files generated by newer versions of Visual Studio (since
>> 2005 I believe) that contain per-machine or per-workspace information. For
>> all intents and purposes these are temporary files that are not checked into
>> version control.
>>
>> The normal file naming convention for these are:
>>
>> project.vcproj.DOMAIN.USER.user
>>
>> Where DOMAIN is the machine/domain name, and USER is the local account
>> name.
>>
>> I found out a couple of years ago that if you rename it to this:
>>
>> project.vcproj.user
>>
>> Visual Studio will treat this as "defaults" for the machine-specific
>> version created using the naming convention I first outlined.
>>
>> The user files are useful for setting debug working directory and command
>> arguments. There are some other things you can set but I have never found a
>> use for them. Since I like to set these two parameters, what I've done is
>> keep my template user file in version control, and use CMake's
>> configure_file() to fill in the command arguments and working directory
>> fields for me. This approach is a good workaround but I'd really like to see
>> CMake generate these for me. Right now I have to keep 1 user file for each
>> version of visual studio that can be used, and configure them differently
>> based on VS IDE selection.
>>
>> Would it be suitable for CMake to incorporate this functionality? If CMake
>> provided built-in support for this, we could create target properties that
>> would set these fields on the target (it would set them on the generated
>> user file instead of the vcproj file like normal target properties would
>> do):
>>
>> set_target_properties( project PROPERTIES
>> DEBUG_COMMAND_ARGUMENTS "-debug -reg"
>> DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
>> )
>>
>> I'd be happy to help implement this should David, Bill, and others find it
>> to be a good idea.
>>
>> PS: I think I can do it without boost this time ;)
>>
>> -
>> Robert Dailey
>
>
>
> --
>
> 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
--
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
Re: [CMake] User configuration files for Visual Studio
I guess I have failed to strike the interest of anyone on this?
-
Robert Dailey
On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey wrote:
> there are .user files generated by newer versions of Visual Studio (since
> 2005 I believe) that contain per-machine or per-workspace information. For
> all intents and purposes these are temporary files that are not checked
> into version control.
>
> The normal file naming convention for these are:
>
> project.vcproj.DOMAIN.USER.user
>
> Where DOMAIN is the machine/domain name, and USER is the local account
> name.
>
> I found out a couple of years ago that if you rename it to this:
>
> project.vcproj.user
>
> Visual Studio will treat this as "defaults" for the machine-specific
> version created using the naming convention I first outlined.
>
> The user files are useful for setting debug working directory and command
> arguments. There are some other things you can set but I have never found a
> use for them. Since I like to set these two parameters, what I've done is
> keep my template user file in version control, and use CMake's
> configure_file() to fill in the command arguments and working directory
> fields for me. This approach is a good workaround but I'd really like to
> see CMake generate these for me. Right now I have to keep 1 user file for
> each version of visual studio that can be used, and configure them
> differently based on VS IDE selection.
>
> Would it be suitable for CMake to incorporate this functionality? If CMake
> provided built-in support for this, we could create target properties that
> would set these fields on the target (it would set them on the generated
> user file instead of the vcproj file like normal target properties would
> do):
>
> set_target_properties( project PROPERTIES
>DEBUG_COMMAND_ARGUMENTS "-debug -reg"
>DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
> )
>
> I'd be happy to help implement this should David, Bill, and others find it
> to be a good idea.
>
> PS: I think I can do it without boost this time ;)
>
> -
> Robert Dailey
>
--
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
[CMake] User configuration files for Visual Studio
there are .user files generated by newer versions of Visual Studio (since
2005 I believe) that contain per-machine or per-workspace information. For
all intents and purposes these are temporary files that are not checked
into version control.
The normal file naming convention for these are:
project.vcproj.DOMAIN.USER.user
Where DOMAIN is the machine/domain name, and USER is the local account name.
I found out a couple of years ago that if you rename it to this:
project.vcproj.user
Visual Studio will treat this as "defaults" for the machine-specific
version created using the naming convention I first outlined.
The user files are useful for setting debug working directory and command
arguments. There are some other things you can set but I have never found a
use for them. Since I like to set these two parameters, what I've done is
keep my template user file in version control, and use CMake's
configure_file() to fill in the command arguments and working directory
fields for me. This approach is a good workaround but I'd really like to
see CMake generate these for me. Right now I have to keep 1 user file for
each version of visual studio that can be used, and configure them
differently based on VS IDE selection.
Would it be suitable for CMake to incorporate this functionality? If CMake
provided built-in support for this, we could create target properties that
would set these fields on the target (it would set them on the generated
user file instead of the vcproj file like normal target properties would
do):
set_target_properties( project PROPERTIES
DEBUG_COMMAND_ARGUMENTS "-debug -reg"
DEBUG_WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
)
I'd be happy to help implement this should David, Bill, and others find it
to be a good idea.
PS: I think I can do it without boost this time ;)
-
Robert Dailey
--
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
