Hi Moazin, I think Werner took the day off today so let me quickly jump in with a few thoughts that might help you until Werner is back :)
> As I start researching about SVG rendering libraries, one thing I'll be > concerned with will be the dependency tree and the size of those libraries. Hell yeah, you don't want to mess with building those yourself, usually ;) > Thinking about the sizes, brought me to the question of how will we be linking > the default SVG Rendering library. For the sake of this question, let's ASSUME > we choose to use `svgnative' with its `cairo' backend. Which of the following > would be our case: > > 1. We specify `svgnative' and `cairo' as a dependency, just like 'libpng' is > defined currently (provided it is configured to be `yes' in ./configure step). > `libpng' is NOT directly a part of `libfreetype.a', rather it's supposed to be > already installed in the system and is dynamically linked within > `libfreetype.so'. The same goes for `harfbuzz' and `graphite2'. Am I correct? > Is this exactly what we will be doing with the `svgnative' and `cairo'? 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) 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. > 2. We make `svgnative' a part of our codebase. Take the responsibility of > compiling it within our build system. At the same time, we specify `cairo' as > an external dependency and dynamically link it within `libfreetype.so'. > > 3. We make everything a part of our codebase. Including `svgnative' and > `cairo' and all of their major dependencies. Sounds like a really horrible > idea given the size of these things. But I wanted to make sure I list > everything that I have in my mind. > Which one is it going to be? Some variation of any one of these? None of > these? Like said above, I'd be surprised if Werner rooted for including other code in FreeType's repository. > My understanding about linking had been really weak. I have learned a lot more > about it with my recent experiences with compiling `svgnative' with its `skia' > port (which I have now successfully done). So, if I have got any major concept > wrong or if I am unaware of common practices, I apologize, please point it out > and I'll read about it. Don't worry; there's really not much going on with linking :) I'll add a few thoughts here, skip it if you feel like I'm telling you stuff you already know; sorry upfront, if that's the case! >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. There's then the difference between dynamic, static + runtime linking but for a general understanding, it all works the same :) Hope I could help at least a bit. If not, let me know, I'll be sitting in front of my computer for a few more hours today. Best Armin _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
