I am currently experimenting with getting Blender compiling with an improved build system (mainly for ease of use and speed). One thing that struck me is the quite messy interdependency between things like blenkernel, blenlibrary, bmesh, imbuf, etc. Which does work with CMake (legacy) but not with modern CMake (using proper target properties) and other build systems.
Now my question is whether this is actually intended or rather a “bug”.
Depending on that I would either:
- separate the headers from the actual compilation units. This is a bit messy because when building an executable you actually have to manually select the necessary implementations then.
- Try to split the libraries further apart so that they can be used without interdependencies. Which might be really challenging ™.
From all the docs I sadly could not find who is actually responsible for the build system.
Any pointers are very welcome.
2 Likes
I remember looking into making the libs shared to improve linker performance, and pretty much ran into the same issue.
I plotted the inter-dependencies between most of the core libs and went ‘nope! not worth the hassle!’
an arrow means ‘uses functions from’ ie bf_blenlib uses functions from extern_wcwidth ( mk_wcwidth /
mk_wcswidth)
1 Like
Nice graph. I think basically things like blenlib and blenkernel are no longer what they were originally meant to be and could be split into 2-3 libraries.
I would like to tackle making the library graph acyclic again but need a few pointers.
- Are forward declarations forbidden? Given the huge amount of header->header includes I get the feeling that forward declarations are forbidden in this codebase.
- Are directories supposed to only contain one library? Most directories only contain one library - which then would mean introducing new libraries.
So 2 years later and it seems this problem still persists. What do you think @ideasman42 - is this worth tackling?
With a recent bump in our cmake version, i took a fresh stab at this recently, transferring clog and guardedalloc to modern targets in D8864. They were low hanging fruit and a nice test case to see how the other devs felt about it.
I think it is worth doing and think it can be done incrementally, we may never detangle the wire nest that are our libs and have shared versions of them but bumping the build system to a place where we don’t have to manually fudge the include folders and sprinkle defines in 40 different places should imho be a reachable goal.
I would then try my luck at draw if that’s ok with you.
i’d wait until D8864 has landed, since it includes some essential tooling
1 Like
Maybe it would be a good idea to have “real” tooling in place.
E.g. a parser for CMakeLists.txt which ensures that certain rules are upheld.
Or how many libraries work with the new vs old way of handling libraries.
while I do see value in making sure all dependencies are properly modeled, the low hanging fruit is pretty obvious at this point and can be easily deduced by looking at the hardcoded include paths for each module. No tooling required.
That being said, not a single core dev has accepted D8864 in nearly a month, so for all I know nothing will happen in this area, I feel you may be getting off to a way too enthusiastic start there.
