I assume yes, very much so. FreeType has never used (git) submodules of sorts (afaik) and quite frankly, even though it got a lot better, submoduling is still pretty painful, even with modern git. (Beware: this is my _personal_ opinion)
I've had a bit of experience with those. Couldn't agree more. Quite painful. You would have to take care of building all of the submodules within your own build system, I guess?
In contrast, using (`linking') external libraries on Linux (FreeType's main target system) is and has always been easy and super-efficient. You don't have to care about _any_ updates (changes to other build systems, e.g.) of those libraries and you can link them in all sorts of funny ways (dynamically [pretty much standard for many things], statically, or even at runtime within your application). Also, you don't have to care about target specific weirdness of those other libraries.
Yea, I didn't actually know that dynamic linking is the standard these days until today. It is amazing how complex dependency trees can be treated with ease using dynamic linking. I compiled a very simple program that uses FreeType today and tried to link everything statically. It's really painful. I had to seek out `.a' files of the dependencies of FreeType and then those of their dependencies. With something as less-dependent as FreeType, the process was hard, I can imagine how terribly hard it would be for more complex things. The size is another issue it solves. Am I correct?
From a library user's perspective, all you (usually) do (on Linux) is include some header files that are provided by the library that you want to use. When using FreeType (as a library), you are tasked with adding `public' header files from the `include/' folder, for example. Side note: many libraries provide their public header files in an `include' folder in their root folder, however, this is not mandatory. Also, when you're using specific `devel'/`dev' versions of libraries, they usually add their public header files to the system-global include folder which automates the process of looking for those headers for you. Then, you can use the functions, structs, defs, etc in these public header files of a library exactly the same way as you usually use your own header files in your projects. The only difference is that you can't find the implementation of these functions in *.c, *.cpp, *.xyz files but ALL functions (!) are hidden in special `executables' (called `libraries'). More precisely, the `machine code' in these libraries is usually neatly precompiled and optimised so you don't have to mess with building anything and getting that right. Instead, you can use these libraries `out of the box' (if a precompiled version is available for your system). The only thing that _you_ (as a user) have to do is tell _your_ compiler where to find these precompiled code blobs. The compiler/linker then takes care of stitching up your application with the precompiled code blob. If that fails (usually an issue with the library) you get linker errors that complain about missing functions etc.
Thank you for writing a very clear explanation. I have been on Linux for some time and have been doing a lot of building from source so have learned these things over time. Your explanation really allowed me to confirm my concepts and verify them as correct, so thank you very much. :)
Regards,
Moazin