Boost: Use Headers instead of building when not required

[dgovil]

Description of Change(s)

When building USD without Python, OIIO or VDB, Boost libs aren't required. In this scenario, it is preferable to just copy over the headers instead and save some time and complexity.

Edit: as subsequently requested, removed the filtering. With filtering, this can reduce the header size from 180M to 37M. Without filtering, the only benefit is that you don't spend time building with B2 when you don't end up using any of its output.

This also has a significant benefit that it allows the core USD build to be supported on platforms that Boost doesn't natively build on yet like iOS and visionOS. It means that the build_usd.py script doesn't need to carry as many patches to Boost itself if someone is just building the core USD library.

This is similar to PR 2914 but can short circuit the entire bootstrap and b2 process, which may still error on platforms that b2 doesn't understand.

• I have verified that all unit tests pass with the proposed changes

• I have submitted a signed Contributor License Agreement

[jesschimein]

Filed as internal issue #USD-9296

[meshula]

Heh nice to see this latest patch reduces the boost footprint in the build directory from ~180MB of headers to ~40MB of headers!

[spiffmon]

Thanks for submitting this, @dgovil , though after consideration, we don't think it's right to take this, just yet, since:

1. We're concerned about testing against all the different boost versions
2. Also concerned about hardcoding transitive dependencies, which may change, version to version
3. We plan to have all boost dependencies except boost::python gone within the next release or two, and after that this PR could be much simpler.

[dgovil]

@spiffmon That's understandable, though most of the header reduction complexity was by request.

If I revert to my initial version of this PR, it just does a straight copy of headers and so is much more straightforward/consistent for all boost versions.

A few alternatives that I'd like to run by you, since this is the basis of our iOS patch and so makes landing those somewhat more complex.

1. I could revert this to just copy all headers and not care about the excess size. (This matches what b2 does already and turns it into a very small PR)

2. I could drop this PR and add B2 patches to the iOS PR. That does make it a little more fragile IMHO, but I could limit the boost version for iOS to 1.82.

3. Leave the iOS patches till after boost is removed.

My worry is that we tie the iOS patches to removal of boost as (IMHO) they could be separable concerns.

Since the PRs are stacked, it's easier to solve them from the root upwards.

[sunyab]

I'd vote to just copy all the headers, and ideally just for header-only libraries. That retains the "don't have to actually build boost" benefits without the maintenance burden, and is no worse from a size perspective than we were before.

[dgovil]

Ooh, I managed to get something working because of the following changes that landed for 24.3

1. Boost 1.82 fixes some stuff and we'd enabled that for Python 3.11
2. My other boost patches to work with our compiler toolchains

It means B2 build now succeeds for iPhone derived platforms without any patches to B2's configs, and just minor changes to the b2 args.

So I'll do two things:

1. I'll uncouple the iOS PR from this completely with that change in place. It just results in some wasted compute and some libs that won't get used.
2. I'll revert this PR to have no filtering.

That way, we can evaluate this PR on its own merits instead of it being tied to the iOS ones. In which case, maybe let's just close this PR out as unnecessary, in favour of the de-boosting effort? Does that sound good to you, @sunyab and @spiffmon ?

[dgovil]

Okay:

1. Decoupled all the iOS PRs from this.
2. Changed this so it does a direct copy of the headers.

But totally feel free to close/reject this PR as well. The only advantage is the time/space savings of not having to run B2 now

[jesschimein]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[sunyab]

Great! Since you're no longer depending on this I'm going to close this out since we're not benefiting much from it, and we're also this close to being rid of the boost dependency (in most cases) anyway. Thanks!