Comment by CamouflagedKiwi
2 days ago
Because you have to build it. If they don't use the same build system as you, you either want to invoke their system, or import it into yours. The former is unappealing if it's 'heavy' or doesn't play well as a subprocess; the latter can take a lot of time if the build process you're replicating is complex.
I've done both before, and seen libraries at various levels of complexity; there is definitely a point where you just want to give up and not use the thing when it's very complex.
This. When step one is "install our weird build system," I'll immediately look for something else that meets my needs. All build systems suck, so everyone thinks they can write a better one, and too many people try. Pretty soon you end up having to learn a majority of this (https://en.wikipedia.org/wiki/List_of_build_automation_softw...) to get your code to compile.
If TCMalloc uses bazel, then you build it with Bazel. It just needs to install itself where you tell it to, and then either it has given you a pkg-config file, or otherwise, your own build system needs some library-finding logic for it ("find module" in CMake terms). Or - are you saying the problem is that you need to install Bazel?
Building complete, optimised binaries can be much more complicated than just linking in a SO/A file. Things like cross-language LTO and PGO can be massive for performance and require integration throughout the build system.
> Or - are you saying the problem is that you need to install Bazel?
That. Then there's Facebook's build system, a few Python and JavaScript build systems, and pretty soon I have installed and have to deal with a half-dozen things that slightly improve upon Make. It's a maintenance burden if I ever have to touch any of these build systems.