Allow linking against pre-built libraries

[chadrik]

First of all, thanks for the amazing contribution!

Now on to the issue.

The cmake build scripts in this project download or clone the source for over a dozen other projects, which is bad for a few reasons:

• It is essentially impossible to build behind a firewall. I started off trying to make internal mirrors of the various git repos that were required, but quickly realized there were also zips and tarballs, so I gave up.
• It is very slow! Our company already has internal builds of every one of these dependencies that we'd just like to reuse, like we do for the other tools we build like USD, OIIO, etc, etc.
• The build log exceeded the maximum size of our CI/CD runner

It's nice to have an uber-build-script that tries to do an end-to-end build but in my experience it's best done in layers. At the lowest level there's the cmake build script for RV, which uses the usual FindXXX.cmake functionality to find all the deps (you can find some good recipes for some of those here) and at the highest level is an optional uber build script that downloads and builds all the deps and then builds RV. This is how USD handles this, for example. That makes it easy for studios that already have a more expansive build orchestrator, e.g. rez or spack, to opt out of the uber-build and just reuse their existing libraries by plugging rv into their build orchestrator.

Thanks!

[rogernelson]

This is the eventual goal. We did a lot of clean up in the build system before open-sourcing the project, moving everything from Makefiles to CMake. Unfortunately, we did not have time to do everything we wanted, and we were hoping the community would help out with some of the "nice to haves" rather than the critical tasks we needed to get done. So on that subject, we would love to discuss ideas or collaborate with anyone interested in this topic.

[chadrik]

Yeah, I totally understand, as I imagine it was a lot of work to get this out the door. Once I get this built and deployed I’ll see if I can tackle “cmake-ifying” a few of the deps. I think the most challenging part of that task will be preserving the download behavior, since it’ll need to move somewhere else. Should there be a higher level CMakeLists with the download and build functionality for all the external project, or should that move into a build script like USD’s build_usd.py? We could even start by copying and modifying that script since it has a lot of functionality that we would need here.

[rogernelson]

We did CMake-ify some of the dependencies. You can take a look at the cmake/dependencies folder to see what we did. It's a mix of FetchContent and ExternalProject_Add calls and some custom scripting too for the more complicated ones (python and pyside). Both have the of the built in calls have the ability to download from git repos built-in. FetchContent is nice because it will effectively add all the CMake targets into your project, but you need to be careful with it might depend on other projects and those might not support FetchContent (some projects like libjpeg do not allow it). Also FetchContent happens at configure time and ExternalProject_Add happens at build time, so FetchContent cannot be parallelized. A lot of what we did in there was modelled after OpenEXR and/or Imath.

I think most of the remaining work would be to take what is in src/pub and move it into cmake/dependencies to have proper CMake builds. At the start of the project all third-party deps were in src/pub, and we moved what was easy to move. The remaining dependencies were left there because they were difficult due to large number of dependencies (sometimes circular) or other complications, so it might be tricky business to get them moved over one-by-one.