On 22/06/2017 13:11, Peter Dimov via Boost wrote:
Thomas Heller wrote:
One way to go here is to have one Config.cmake for each build type. For example structured like this:
lib/cmake/boost-vc141-mt-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-gd-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-gd-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-s-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-s-1_65-static/boost_system-config.cmake lib/cmake/boost-vc141-mt-sgd-1_65-dynamic/boost_system-config.cmake lib/cmake/boost-vc141-mt-sgd-1_65-static/boost_system-config.cmake
Yikes, I thought this was supposed to make things simpler/better? Whatever we end up with, it needs to be something that cmake-o-phobes like myself that have never looked inside a cmake file can still maintain relatively easily. With regard to Windows / msvc usage, I see two main usage requirements: 1) The ability to build all the variants we do at present, so that folks can just build Boost as they do now, and then point their IDE at the directory containing the .lib files. 2) The ability to take the Visual Studio files generated by CMake, and add the library targets directly to their own project "solutions" so that their own projects can reference them. #1 we do already, #2 would be a very useful feature for Visual Studio users - way more useful than being able to reference Boost from other CMake files for folks like me. Probably the easiest way to support those two, would be to have a *single* CMake target for each library (which generates a single VS project, OK may have to be 2 - one static and one dll), and then a separate install step that renames the lib/dll depending on how it was built. I also noticed someone wanting to link debug application with release Boost library: but you can't in general do that with the Visual Studio builds - the whole reason we support all these variants is that they are built against different runtime libraries and are therefore binary incompatible. What you can do, is build a debug library (as in links to the debug runtime) but turn on optimizations. BTW These variants along with auto-linking were things I introduced with Regex long before it was in Boost - before that I used to get a couple of support requests a week from folks trying to link incompatible binaries, building all the variants along with the auto-linking killed that problem dead. And boost usage has exploded hugely since those early days. Just trying to emphasise how important the feature is ;) And now I'll go back to lurking, John. --- This email has been checked for viruses by AVG. http://www.avg.com