Let me think about the HarfBuzz co-dependency a bit... On Mon, May 18, 2020 at 12:26 PM Behdad Esfahbod <beh...@behdad.org> wrote:
> Hi David, > > Thanks for experimenting with this! > > I encourage you to explore removing the Module and Service abstraction > completely. We did that in Pango a couple of years ago and never looked > back... > > I'll reply to your original request this week. Threadsafety and lack of a > functional separate size object from face is by far the biggest pain point > of FreeType for heavy users of the library. > > b > > On Sun, May 17, 2020 at 10:45 AM David Turner <da...@freetype.org> wrote: > >> Continuing my own thread, after taking the time to experiment a little. >> >> First, I've refactored the build system so we turn the rules.mk into >> declarative files (instead of Makefile fragments) and get rid of the >> module.mk files. >> This allowed me to write a Python script to parse modules.cfg and the >> various rules.mk to generate a Makefile based on the configuration >> expressed there. >> The script is called meta-build.py, and could be easily extended to >> generate something else if needed, but I haven't gone further than that. >> However, this let me explore with the exact details on how we configure >> our build, and the various options to build the library (the generated >> Makefile allows you to build three variants of the library: a static >> library and a shared library both compiled with -fPIC, and a static library >> compiled without it). >> >> Second, I wrote support files for the Meson build for the library. It is >> similar to the CMakeLists.txt version, except for the installation / >> packaging part. It was a good way to get used to the tool and to compare >> its system/header/library probing features. >> In the end, and this is personal opinion, I find Meson cleaner than >> CMake, sometimes much cleaner, though it has its own little warts that were >> a bit surprising, as a new comer. Both systems are so much better than >> auto-tools however. >> >> I believe that the ability for any developer to just download a release >> archive and run "./configure && make" to get a *default build* of the >> library (and "make install" to install) is really important. I insist on >> the "default" here, because we have a sophisticated customization system, >> which was designed in a different time. >> In other words, before considering switching the build to something else, >> I propose the following: >> >> - Whatever we do, ensuring that "./configure && make && make install" >> continues to work on Posix systems without extra dependencies. This would >> only be guaranteed to work on a default build of the library (i.e. without >> module customization). Configure options would still be provided as usual >> to handle external dependencies like zlib, libz2, etc. >> >> - I would like to drop the dynamic module instantiation / lookup code >> from the library, to simplify certain code paths. The ability to inject at >> runtime a new FT_Module was designed at a time where it was expected that >> people would write custom modules for proprietary/custom font formats, and >> tools like git which make it easy to rebase changes on top of an upstream >> project were not available or still very unfamiliar. These days, anyone can >> create its own fork of an open-source library to add custom features for >> its own little embedded project. This means no more modules.cfg, and >> ftmodule.h auto-generation, which are fortunately implementation details. >> For ABI stability, we will have to keep functions like FT_Add_Module(), but >> just change them to return an FT_Err_Unimplemented_Feature error code. >> >> - I would like to ensure src/base/ftsystem.c does the right thing for all >> systems. These days, we can avoid probing for <unistd.h> and <fcntl.h> and >> assume a Posix system provides a valid mmap() / munmap() implementation. >> This will remove one more reason to use auto-tools. >> - Similarly, there are several versions of ftdebug.c which are >> essentially similar except for two things: How messages are sent to "the >> log" (stderr by default), and how to parse the FT2_DEBUG environment >> variable (when such thing exists). These two things can be encapsulated in >> a separate file. >> - Also, we don't need to support 8.3 Filepathnames (DOS and Windows 9x >> development are long dead), so we can finally use longer filenames (e.g. >> ftdebug_posix.cc, ftdebug_windows.cc, etc..) to better differentiate the >> files under src/base/ instead of sprinkling them under builds/<system>/ >> - It also means we can probably drop some of the ugly macros for header >> files we're using (still provide them for the API, but change all users >> otherwise). Yeah! >> - Regarding ftdebug.c and logging, we probably want the customizable >> "message" function to take several parameters, e.g.: void >> FT_Log_Message(int trace_component, int trace_level, const char* fmt, >> va_list args). It's possible to consider trace events (i.e. "start/stop") >> to generate flame graph that are easier to read. >> - There are different versions of ftconfig.h, with a ton of stuff shared >> between them, we should probably move these to common header files whenever >> possible. >> - Similarly ftoption.h contains both user-selectable options, and things >> that are more tweaks for the implementation that a typical developer will >> never have to care for. I suggest we move the latter to an internal header >> instead. >> - There are many things I'd like to get rid of, but apparently >> >> - Finally, the largest issue I've seen is the dependency on Harfbuzz. The >> situation where both libraries depend on each other is a little bit >> ridiculous. I wonder how much of Harfbuzz we need, and if it's worth >> re-implementing in FreeType2 itself. But something tells me implementing >> hb_shape() can be really subtle. Any informed opinions on this? >> >> I'm adding two git bundles related to the experiments I've described >> there (nothing to consider for submission, imho, for now). >> I'll prepare some patches to simplify our existing build files and >> customization process as explained above, unless someone has better >> suggestions. >> >> Regards, >> >> - Digit >> >> >> >> >> >> >> >> >> >> Le jeu. 30 avr. 2020 à 01:39, David Turner <da...@freetype.org> a écrit : >> >>> Starting a thread here to discuss potential build system improvements >>> for FreeType. >>> >>> The current FreeType 2 build system has many flaws. To its credit, it >>> was designed in a very different time, when things like CMake / Meson / >>> Ninja/ Maven / GN / Bazel didn't even exist, when Autotools was considered >>> the best system to configure your build (ah!), and GNU Make 3.81 was >>> considered new and bleeding edge, and didn't necessarily exist for all >>> platforms. I'm not even sure pkg-config was available on all Linux distros >>> until quite a long time. As I said ... very different times. >>> >>> Despite that, it was also designed to make FreeType buildable on a >>> maximum amount of systems, and I attribute part of its success to that >>> specific feature, especially in the embedded world. While we probably no >>> longer care about developers using DOS and OS/2 systems to build the >>> library, I would really appreciate if any replacement could continue in >>> this direction. >>> >>> I think it would also be acceptable if the build system used to develop >>> FreeType itself, might be different than the one used by other developers >>> that simply want to use it in their own projects. For example something >>> that can build and run tests easily with sanitizers, fuzzing, remote bots >>> and other goodies, or can integrate well with a continuous integration >>> system. While at the same time, being able to generate simple Makefiles / >>> CMakefiles / BUILD / BUILD.gn / whatever corresponding to a specific >>> configuration of the library (which is what 95% of developers using the >>> library need). >>> >>> I have experience with CMake (I find it a vast improvement over >>> auto-tools for package / feature detection, but a hot mess for about >>> anything else), GN/Ninja (very powerful, but essentially requires too much >>> dependencies to get the most out of it) and Bazel (can be hard to get into, >>> very powerful, but requirements are a bit crazy at the moment). I'm curious >>> about Meson. >>> >>> I don't have something specific to propose, but that's my current point >>> of view. I may be wrong or misguided, so please share your feedback in this >>> thread. >>> >>> Let the flame^W war^W games begin :-) >>> >>> - David >>> >>> > > -- > behdad > http://behdad.org/ > -- behdad http://behdad.org/
