That sounds very good.
Personally I'd be very happy to see the header inclusion macros gone where
possible, because they confuse both users and IDEs. I would also be very
happy to see meson support, because it seems to be gaining usage nicely and
I do find it nicer than CMake.
I'd be a bit sad if CMake support would go away if there was no meson
support, however with meson support I would not care that much about CMake.
One of the features with both CMake and meson I find useful is ability to
use other projects as subprojects, directly in source form, often as
git(hub) submodules. This makes it easy to quickly navigate to the source
of everything in the IDE. Another benefit is that you can use latest
version of the library, perhaps your own fork with pull requests pending,
without having to install anything on your system.
On Sun, May 17, 2020, 20:45 David Turner 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 and 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//
> - 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
>
