Can't link against custom static boost build

[ix-dcourtois]

Description of Issue

When building USD against pre-built libraries using CMake, Boost_USE_STATIC_LIBS option is ignored, resulting in linking errors if the prebuilt boost libs were built as static libs.

The fix is fairly simple, and I have a fix (and pull request) ready to allow users to use the Boost_USE_STATIC_LIBS. I'm posting this issue as per the "Contributing to USD" guide :)

Steps to Reproduce

1. Build Boost as static libraries only.
2. Build USD using the following options during configuration: -DBOOST_ROOT=<path_to_boost> -DBoost_USE_STATIC_LIBS=On
3. Results in LINK : fatal error LNK1104: cannot open file 'boost_regex-vc140-mt-1_61.lib'

System Information (OS, Hardware)

Windows 10 (but probably on any platform)

Package Versions

0.8.x and dev branch

Build Flags

[jtran56]

Filed as internal issue #156962.

[sunyab]

@ix-dcourtois thanks for posting this! One concern I have about this change is that linking boost::python statically leads to all sorts of problems with the Python bindings. That's one of the reasons we forced the use of the dynamic libraries originally.

I get the desire to be able to use the static boost libs, though. I wonder if there's some way we can partition things so that we allow the static versions of the boost libs except boost::python?

[ix-dcourtois]

@sunyab Hi, thanks for taking the time to check this PR.

There seems to be a way to do that, but it could be a bit tricky. In the FindBoost.cmake module, there an example which goes like this:

   set(Boost_USE_STATIC_LIBS        ON)
   # ... some other stuff
   find_package(Boost 1.36.0 COMPONENTS date_time filesystem system ...)
   if(Boost_FOUND)
     include_directories(${Boost_INCLUDE_DIRS})
     add_executable(foo foo.cc)
     target_link_libraries(foo ${Boost_LIBRARIES})
   endif()

So maybe this kind of thing could be used to first get the static version of boost::python, and then invoked again with set(Boost_USE_STATIC_LIBS OFF) for the other ones.

The problem I see with this, is that:

1. it's awfully messy.
2. my guess is that there will be lot's of problems coming from linking some libs dynamically and some other statically
3. users usually kind of expect the standard options such as Boost_USE_STATIC_LIBS to do what the doc says (e.g. apply to all libs) and would probably be a bit surprised if it applied on all libs except python :)

To put this pull request in context, here's our use case: we are already using and linking boost internally (as well as openimageio and various other libs used by USD), but we're using static versions of the libs. So in order to use USD in our software, we need to build against our prebuilt versions. Since we don't need the python bindings for now, we don't have the problem you mentioned. This PR fixes only this case.
And as I said, it doesn't change the default behavior (e.g. if users do not use Boost_USE_STATIC_LIBS, USD will continue linking against dynamic boost libs)

I'll try to check what the problem is with the Python bindings, but I'm not sure it can be fixed easily :p

[sunyab]

We discussed this a bit and we think it's good to give users the ability to opt in to this behavior at their own risk rather than completely disallow it. I've merged in your pull request, but also note the follow-up commit f9c5d50. Thanks!