The Mesa3D drivers have been notorious for taking in the entire LLVM kitchen sink (debugger and LSP server included) as a runtime dependency (There is even a FBSD Wiki entry about it).
But when looked at closely, the dependency only revolves around the LLVM libraries used as a backed for shader compilation and etc, so there isn't any need to depend on the entirety of the LLVM tool-chain, which can be few gigabytes in size, all that is needed is to depend on, are the dynamic libraries provided by LLVM, that are much, much smaller in size.
Many Linux systems, take this approach and split LLVM into two (or even more) sub-packages separating the toolset from the back-end libraries, and make packages like Mesa3D only depend on the "llvm-libs/llvm-runtime" sub-package, significantly reducing the disk space needed for installing the dependents of LLVM libraries. (Arch Linux as an example)
GhostBSD is also actively trying to implement such split in their own ports tree fork, to save up space in their distribution images.
So, few days ago I was digging around Mesa3D's source tree when I found these,lines:
Intrigued, I quickly modded the graphics/mesa-dri & graphics/mesa-libs ports and passed in some fixes to make them build, reinstalled them,
As of now I have only tested it with my Radeon GPU & XLibre, and everything (OpenGL, DRI, Vulkan ...) is running perfectly as it did before with the non-static version.
I'm generally not a big fan of static compilation in most cases, but here with Mesa3D, when built statically about 10+MB is added to its package's size while cutting a massive 2GB dependency, which also has many duplicated functionalities with the subset of LLVM tool-chain bundled in base, and on top of that it makes the Mesa3D drivers decoupled (at least in runtime) from the different versions of LLVM you may want to install/remove for development.
Here is the ports tree diff of the changes I made to make this work: Compare.
So, I'm posting this here for ideas, whether or not this is possible to include in the port, if it makes sense and ...
But when looked at closely, the dependency only revolves around the LLVM libraries used as a backed for shader compilation and etc, so there isn't any need to depend on the entirety of the LLVM tool-chain, which can be few gigabytes in size, all that is needed is to depend on, are the dynamic libraries provided by LLVM, that are much, much smaller in size.
Many Linux systems, take this approach and split LLVM into two (or even more) sub-packages separating the toolset from the back-end libraries, and make packages like Mesa3D only depend on the "llvm-libs/llvm-runtime" sub-package, significantly reducing the disk space needed for installing the dependents of LLVM libraries. (Arch Linux as an example)
GhostBSD is also actively trying to implement such split in their own ports tree fork, to save up space in their distribution images.
So, few days ago I was digging around Mesa3D's source tree when I found these,lines:
Code:
option(
'shared-llvm',
type : 'feature',
description : 'Whether to link LLVM shared or statically.'
)
option(
'static-libclc',
type : 'array',
value : [],
choices : ['spirv', 'spirv64', 'all'],
description : 'Link libclc SPIR-V statically.',
)
Intrigued, I quickly modded the graphics/mesa-dri & graphics/mesa-libs ports and passed in some fixes to make them build, reinstalled them,
pkg autoremoved and long story short I now have games/Xonotic running on the next window at 300-120FPS [Ultra setting] without any version of LLVM installed on my system (aside form the base version).As of now I have only tested it with my Radeon GPU & XLibre, and everything (OpenGL, DRI, Vulkan ...) is running perfectly as it did before with the non-static version.
I'm generally not a big fan of static compilation in most cases, but here with Mesa3D, when built statically about 10+MB is added to its package's size while cutting a massive 2GB dependency, which also has many duplicated functionalities with the subset of LLVM tool-chain bundled in base, and on top of that it makes the Mesa3D drivers decoupled (at least in runtime) from the different versions of LLVM you may want to install/remove for development.
Here is the ports tree diff of the changes I made to make this work: Compare.
So, I'm posting this here for ideas, whether or not this is possible to include in the port, if it makes sense and ...