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 Jackson Principal Software Engineer
BlueQuartz Software Dayton, 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 <rcdai...@gmail.com> 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
