You can do even better than this. :) Take a look at the predefined Macros in VS. You'll find all sorts of things you can use to select 32 vs. 64 bit, which version of VS you're using, debug vs. release, etc. You can construct paths/ filenames using these macros to select what you want. If that isn't enough, you can create subordinate property files that define additional macros that get pulled in automatically. For example, find attached a version.props file that I use to select which version of a MongoDB client to select and how to find the relevant client source/lib files. I have subdirectories named based on the version of VS I'm using, with a different version.props file in each. The VS2015.props file also attached selects which version.props file I want. In this particular case I set an environment variable to identify whether I want VS2015.props or VS2012.props, etc. I then replaced this line: <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" /> in my VS project files with this line: <Import Project="$(FDX_HOME)\build\$(FDX_DEFAULT_TOOLSET).props" /> Where $(FDX_DEFAULT_TOOLSET) is the environment variable I set to select the version of VS I want to use. Of course, you can use the same approach to select based on any criteria you want. Regards, Steve H. -----Original Message----- From: Marcel Raad [mailto:raad@teamviewer.com] Sent: Thursday, May 19, 2016 9:42 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] How to write one property page .props to select the right x86 or x64 Boost libraries folder automatically using Visual Studio pabristow wrote

I have downloaded the shiny new release boost_1_61_0_b1 and am trying to set up so that I can test a lot of Boost-ish console applications using both 32 and 64-bit.

This is easier with bjam, but I'd like to use the Visual studio IDE too.

I'd like a single property page that can be placed in the same folder as my .sln file and added to each and every project.

(or better, made the default for all projects).

I have a I:\boost_1_61_0_b1; as the include directory, and that is common to all configurations and platforms.

But the libraries files are in two separate folders because the name does not yet include the platform :-(

Linking to lib file: libboost_chrono-vc140-mt-gd-1_61.lib

lib32-msvc-14.0 and lib64-msvc-14.0

Googling gives some suggestions to select the right folder for libraries, but I wonder if anyone has found a slick solution?

(I'll edit the property xml if necessary - it would seem that the IDE GUI tool isn't up to the job?)

In the "Link" section of the property sheet XML file: <AdditionalLibraryDirectories>I:\boost_1_61_0_b1\lib$(PlatformArchitecture)-msvc-14.0\;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories> You can also do this in the GUI via Linker -> General -> Additional Library Directories. Or, to have more flexibility with the path, but not possible via the GUI: <AdditionalLibraryDirectories Condition="'$(PlatformTarget)'=='x86'">I:\boost_1_61_0_b1\lib32-msvc-14.0\;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories> <AdditionalLibraryDirectories Condition="'$(PlatformTarget)'=='x64'">I:\boost_1_61_0_b1\lib64-msvc-14.0\;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories> Hope that helps, Marcel -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-write-one-property-page-props-to-s... Sent from the Boost - Users mailing list archive at Nabble.com.

Why don't you use property sheets? Something like adding user macro (in property sheets manager), like ThirdPartiesLibs with value like $(SolutionDir)..\ThirdParty\Libs\$(PlatformName)\$(Configuration)\ And then just add the macro to Additional Libraries Directories under Linker/General, just insert the macro there - $(ThirdPartiesLib). Now, any project using this property sheet will inherit the additional libraries from the property sheet value and that it, you don't have anything to do, no XML file editing "geekery". We have done it for years, but recently switched to Boost Native Nuget Packages which is a nice option to consider [cid:image002.png@01D1B3F9.D8B404C0] From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Paul A. Bristow Sent: Friday, May 20, 2016 12:06 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] How to write one property page .props to select the right x86 or x64 Boost libraries folder automatically using Visual Studio From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Hickman, Steve (AdvTech) Sent: 20 May 2016 03:51 To: boost-users@lists.boost.orgmailto:boost-users@lists.boost.org Subject: Re: [Boost-users] How to write one property page .props to select the right x86 or x64 Boost libraries folder automatically using Visual Studio <snip>

I have downloaded the shiny new release boost_1_61_0_b1 and am trying to set up so that I can test a lot of Boost-ish console applications using both 32 and 64-bit.

This is easier with bjam, but I'd like to use the Visual studio IDE too.

I'd like a single property page that can be placed in the same folder as my .sln file and added to each and every project.

(or better, made the default for all projects).

I have a I:\boost_1_61_0_b1; as the include directory, and that is common to all configurations and platforms.

But the libraries files are in two separate folders because the name does not yet include the platform :-(

Linking to lib file: libboost_chrono-vc140-mt-gd-1_61.lib

lib32-msvc-14.0 and lib64-msvc-14.0

Googling gives some suggestions to select the right folder for libraries, but I wonder if anyone has found a slick solution?

Thanks to all those who gave several valuable suggestions. The key info is that for editing properties the IDE GUI isn't (wo)man enough for this task, and that one needs to roll up sleeves and dig into the XML props files, use the long list of macros ... and hours of fun can be had. In the end I used <LibraryPath>I:\boost_1_61_0_b1\lib$(PlatformArchitecture)-msvc-14.0;$(LibraryPath)</LibraryPath> where $(PlatformArchitecture) produces 32 or 64 Many thanks. Paul PS I still think it would be much more convenient and consistent if the library name included the 32 or 64 as we previously discussed. Then autolinking would still 'just work' without this geekery. But maybe nobody is interested in 32 bit any more? -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-write-one-property-page-props-to-s... Sent from the Boost - Users mailing list archive at Nabble.com.