-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exclusion of static libs for static runtime usage #8
Comments
We could hack around this in principle but it seems to me that setting |
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:
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).The text was updated successfully, but these errors were encountered: