I’d appreciate to get insight about building external libraries needed for building Blender on Linux. Why is install_deps.shaccording to instructions preferred overmake deps approach? Any general guidelines when to prefer make deps instead?
Background info: I try to build customized libs (pyopenvdb) into Blender, so I can’t just download and use prebuilt libs. According to Ubuntu Linux instructions, the preferred way is to use install_deps.sh. I’ve now spent a few days trying to modify it to my needs, but I still have issues with it. Now, I decided to give make deps(building approach used by platform maintainers) a try. It seems to build everything (=slow), but it seems much more robust and easier to reconfigure than install_deps.sh. Thanks!
The AFAIK script install_deps.sh will build all the Blender libraries that have not been found in the linux system, make deps will build all the Blender request libraries having as final result the same folder library as the pre-compiled one released by Blender. I’m not expert but adding a new library can be done using all three ways of obtaining the libraries, the new library should be added to the cmake scripts and the blender code in order to be used
post scriptum I’m not a developer or maintainer of the system, so I apologize if what I write above is wrong or incorrect
The suggested way to obtain libraries is using the pre-compiled ones. I think they are automatically downloaded when running make or make update from the source directory. You can use install_deps.sh for compiling the libs on your own, but only if you really want to do that. There were discussions about removing it even.
make deps is just for platform maintainers, it’s really not recommended for other people to use.
tricky one, normally i’d say you are right, however @tkeskita explicitly mentions he’s looking to make some modifications to the libs so telling him to just use the SVN libs isn’t going to be all that useful to him.
There’s 3 options for getting blenders required dependencies
install_deps.sh this will try to re-use what it can from a distro’s package manager and build the things it cannot satisfy, this used to be the default way, supporting all possible distributions with a single script is on the tricky side and there will now and then be issues.
SVN libs, this is relatively new and is the recommended way currently, given nothing has to be build tends to be problem free for most people (although tiny hiccups do happen where cmake somehow still erroneously picks up libs from outside our lib folders)
make deps , this is the script platform maintainers use to build the libraries from 2, it is however build for and maintained by the platform devs, it it not recommended end users use this, however if you are looking to make changes to the libraries this would be the place. However it has the same shortcomings as 1. supporting all possible distro’s with a single script is just bound to run into issues, and given the target audience of this script (platform devs) support for build issues is going to be on the limited side of things.
Thanks for info! About make deps, can you please comment on the lib building philosophy: It seems that each library is first built and installed under build_linux/deps/Release/xxx, and at some later point selected files from those are “harvested” to the final location like lib/linux_x86_64/xxx. Now, it looks like the custom built Python is not used when building custom OSL. Is it a conscious choice not to use custom built Python in the subsequent build process or just something that has evolved like this?
When building pyopenvdb, there is need to increase dependencies: Custom Boost needs custom Python, and pyopenvdb needs custom Boost. My issue with OSL is currently make deps fails because Xubuntu 20.04 does not by default provide a “python” system binary. To fix these issues I’m now trying to look into how to make building and installation of libraries in correct order, and specifically, to start by building and installing Python.
PS. I like make deps. It is easier to control building than with install_deps.sh. Thanks!
The buildscript was started for windows, when i started it there was already an existing SVN lib folder that was (what i can only assume) being maintained manually, so the build script had to delver a drop in replacement which included some fudging of the filenames and cherry picking the things we needed vs the things that got build but we have no intention of shipping (most libraries ship with some demo’s/examples/tests etc that we just don’t want to ship)
so the libs build into a release folder and pick up their own dependencies from there, but once it’s all said and done, there is a harvest phase that’ll just pick the bits we want and put them in a folder structure we expect. (On windows this done directly after each individual sub project builds, while mac/linux has a single harvest for al libs)
as for the gaining dependencies, the process is pretty much universal.
add the new dep into the add_dependencies call so it will be build in the right order
fudge the cmake xxx_EXTRA_ARGS variable to help it find the new dependency this differs a bit per dep and you’ll just have to kinda find your way around there.
)