Open mellery451 opened 5 years ago
We could hack around this in principle but it seems to me that setting Boost_USE_STATIC_RUNTIME
is correct to reject libraries built with the shared runtime. Is the mistake not in the consuming app, which should only request static runtime when it means it, guarded by if(WIN32)
?
ok - that's an interesting point. I could see the argument for pushing this on to the consuming side I guess.
I agree with @pdimov after checking e.g. FindBoost.
Examples:
# Example to find Boost headers and some *static* libraries::
#
# set(Boost_USE_STATIC_LIBS ON) # only find static libs
# set(Boost_USE_MULTITHREADED ON)
# set(Boost_USE_STATIC_RUNTIME OFF)
To disable the ambiguous behavior, the user need only set Boost_USE_STATIC_RUNTIME either ON or OFF.
Only real difference is on non-versioned layout in which you had shared and static libs of "unknown" properties and FindBoost would pick them anyway.
Question though: Where does static_runtime actually has an effect? Could it be disabled for cases where it really has no effect?
If I do a build with default settings (e.g. just
./b2 install
) on linux, I get dynamic and static libs built using thesystem
naming convention. By default, boost assumes a shared runtime. For static libs, however, does it really matter? For instance, my consuming application specifies bothBoost_USE_STATIC_LIBS
andBoost_USE_STATIC_RUNTIME
and thus the default install fails to find the library because of this cmake config code (just using chrono as an example here) :When I switch to a
tagged
layout and build versions for both static and shared runtime, I get two copies of what appear to be the same static library. Couldn't we just make an exception and allow the system layout to work for either runtime choice? I realize this might be OS dependent since windows is clearly different in this regard and apple-clang doesn't allow static runtime at all (I believe).