On 28/04/2016 08:44, Michael Powell wrote:
On Wed, Apr 27, 2016 at 1:17 AM, degski
wrote: Maybe thiis is not fully helpfull to the above, but I do change the props file in:
You're right, that is interesting. That works until you need to rebuild your dev environment. Bottom line is, the settings, directories, etc, should ultimately travel with the project.
Rather than changing that file, I use a hierarchy of props files. (You can attach property files to VS projects via the slightly-hidden View -> Other Windows -> Property Manager.) For example, I have a boost.props file that contains only an import of a specific version props file (eg. <Import Project="boost_1_60_0\boost.props" />) and individual props files in each version dir that contain the actual build settings for that version. This way, projects that should use the latest Boost installed on a given dev PC just link to the base boost.props file, while projects that need a specific version (generally for historic reasons) link to the file in the version-specific directory. (Due to the size of Boost, I usually also have the "real" files on a network share that is mapped to a standard drive letter on different PCs, and another just-import props file in source control that redirects to the appropriate props file on the share; this is what the projects actually link to.) This lets different projects build with different versions of Boost intentionally, and to have a central place to upgrade most projects to the newest Boost version when one is added to the share.