[Boost-users] [Regex] Has build location changed between 1.34.1 and 1.64.0 ?

Subject: [Boost-users] [Regex] Has build location changed between 1.34.1 and 1.64.0 ?
From: Kerry, Richard (richard.kerry_at_[hidden])
Date: 2017-05-22 10:25:33

I've just added Boost Regex to a new project.  It is the first time I've done that for quite a long time (several years) and I'm left wondering whether Regex's standard build location has been changed, or whether I've missed a detail in the instructions.

The last one I did was Boost version 1.34.1, under Visual Studio 6.
The one I have just done is Boost version 1.64.0, under Visual Studio 12, aka Visual Studio 2013.

To build 1.34.1 (on VC6) I run "bjam --toolset=msvc --with-regex stage".
This creates two folders - "bin.v2" and "stage".
Bin.v2 is where all the intermediate files are written.
Stage/lib is where the final outputs are written.  There are a number of different ones built; for all the various static/dynamic, single/multi-threading, debug/release options.

Because of the auto-link stuff I just #include <boost/regex.hpp> in my project, and because of the use of #pragma comments in boost, the Link pass picks up the correct library file-name, provided I have included $(BOOSTDIR)\stage\lib in the linker's list of folders to search.

(%BOOSTDIR% being my chosen download/build location)

To build 1.64.0 I've followed the current instructions.  I ran "b2 regex", which built a dll, which is not what I want.  I then ran "b2 regex link=static", which build the static lib I wanted.  However, the lib is left in a folder a long way down from the bin.v2 folder, which is where I expected it to be.  It's in bin.v2\libs\regex\build\msvc-12\debug\link-static\threading-multi.
Hence, I need to know all the build settings to work out the folder name.  On the file-name side this is all hidden from my by the auto-link system, which builds the lib file's name from the various option settings.
Having the name built automatically but not the path leads me to suspect I've missed something....

So:
Is there an instruction I've missed to get all the built products (dlls or libs) put in a common (not too deep) location ?  (so the auto-link system will be sufficient to find it given just one linker folder location)
Is there an instruction I've missed to get all the combinations (static/dynamic, single/multi-threading, debug/release) built ?  (rather than one at a time)

Regards,
Richard.

Richard Kerry
BNCS Engineer, SI SOL Telco & Media Vertical Practice
T: [phone]
M: [phone]
4 Triton Square, Regent’s Place, London NW1 3HG
richard.kerry_at_[hidden]<mailto:richard.kerry_at_[hidden]>

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.</
Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983.

This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.