Support for Boost_USE_MULTITHREADED missing

boostorg / boost_install

8 stars 30 forks source link

Support for Boost_USE_MULTITHREADED missing #13

Closed dennisklein closed 4 years ago

dennisklein commented 4 years ago

See https://gitlab.kitware.com/cmake/cmake/issues/19714.

I have not verified if one can legally end up in this state or if the user has installed non-mt and mt variants into the same existing prefix.

If it is legal, we would need support for Boost_USE_MULTITHREADED,
if it is illegal, we should probably replace the variant globbing with an explicit list or clean the cmake package directories before installing.

pdimov commented 4 years ago

I never expected anyone to still use single-threaded builds, let alone install both. Looks like I was wrong in this assumption of mine.

drjasonharrison-vp-eio commented 4 years ago

Note that the home brew command brew install boost was used to install the installation of boost with non-mt and mt variants into the same existing prefix.

So the brew bottle contained both variants.

dennisklein commented 4 years ago

So the brew bottle contained both variants.

Thx, that answers my question above (homebrew uses threading=multi,single).

pdimov commented 4 years ago

Should be fixed now.

dennisklein commented 4 years ago

Should be fixed now.

Hm, but the default is still depending on what the globbing returns last, is it not? If Boost_USE_MULTITHREADED is not defined, it shall default to choosing the mt variant, if available.

pdimov commented 4 years ago

I know that this is how FindBoost works, but BoostConfig (in the way things are currently architected) can't do "use X if available, else Y." Whether a variant is accepted or rejected cannot depend on whether another variant is available.

dennisklein commented 4 years ago

I know that this is how FindBoost works, but BoostConfig (in the way things are currently architected) can't do "use X if available, else Y." Whether a variant is accepted or rejected cannot depend on whether another variant is available.

In this matter, I am anyways just the messenger. But if you think it is a good idea to change the existing find_package(Boost) UX here, it is your right to do so, even though I personally think the argument you presented for it is rather poor. Thx, I guess the issue is resolved then.