Re: Build system considerations

[David Turner]

Le mar. 19 mai 2020 à 14:09, Hugh McMaster  a
écrit :

> On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > > - Meson as the primary build system for FreeType developers, which
> > >   includes the ability to run tests, sanitizers, coverage analysis,
> > >   etc.
> >
> > It seems that Meson can create cmake package files, and probably build
> > scripts, too.  Wouldn't that be the best solution?  I can also imagine
> > that Meson builds `configure.ac`...
>
> Is there any opportunity to avoid modifying ftoption.h directly to
> enable, say, subpixel rendering with a new build system? Carrying
> permanent patches for downstream packaging is annoying.
>
> Personally, I'd like to be able to enable various options via
> configure flags or a configurable file (JSON, anyone?) that's not a C
> header. Python could do nicely here.
>
> I think there is an opportunity here. The current customization scheme was
designed for
embedded system development where you could not assume anything fancy in the
development environment (e.g. developing on DOS or Win9x), so modifying
header files
and relying on GNU Make was the sanest possible option at the time. The
auto-tools
scripts came after that, which shows.

We probably want to introduce that gradually though (i.e. add the configure
option while
still supporting custom ftoption.h in a first step, and warning about the
fact that the latter
will change in the future, probably with some judicious use of #warning and
macros).

But for now, I'd rather work on removing the modules/driver system from the
implementation,
which also touches the subject of customizability of the build, which is
still very important to me.


> Other than that, the removal of RPATHs should be revisited. That's a
> topic for another thread.
>

Yes, please start a thread about the issue and why you think it's a
good/bad idea.

Re: Build system considerations

[Alexei Podtelezhnikov]

On Tue, May 19, 2020 at 10:59 AM Ben Wagner  wrote:
> > [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates
> > between ClearType and Harmony algorithms. Most users won't be able
> > to tell them apart.]
>
> Note that some users of FreeType are never going to use subpixel
> rendering at runtime and could do without the code. The actual amount
> of code is pretty negligible, but if they are never going to use it
> it's just extra weight, so it's nice to be able to configure it out,
> no matter how small the extra code for it is.

Ben,
It is less than negligible, it is nothing. Literally:
- Harmony only shifts the outline around (6 extra function calls)
- ClearType scales the outline and scales it back, plus filtering.

This is nothing in comparison to calculating the bounding boxes,
allocating the memory, Bezier flattening, and actual rendering.
The whole smooth.o is now only 88k. The Harmony overhead is not more
than 5% or 4k. Why bother?

Alexei

Re: Build system considerations

[Ben Wagner]

Le mar. 19 mai 2020 à 10:05, Alexei Podtelezhnikov
 a écrit :
>
> On Tue, May 19, 2020 at 8:09 AM Hugh McMaster  
> wrote:
> > Is there any opportunity to avoid modifying ftoption.h directly to
> > enable, say, subpixel rendering with a new build system? Carrying
> > permanent patches for downstream packaging is annoying.
>
> [Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates
> between ClearType and Harmony algorithms. Most users won't be able
> to tell them apart.]

Note that some users of FreeType are never going to use subpixel
rendering at runtime and could do without the code. The actual amount
of code is pretty negligible, but if they are never going to use it
it's just extra weight, so it's nice to be able to configure it out,
no matter how small the extra code for it is.

> > Personally, I'd like to be able to enable various options via
> > configure flags or a configurable file (JSON, anyone?) that's not a C
> > header. Python could do nicely here.
>
> One would think that modules.cfg is a configurable file like that but it turns
> out that Chromium finds special ftmodule.h more convenient. We also have to
> accommodate the less fortunate without Python on embedded systems.

Chromium currently finds the ftmodule.h a convenient way to tell the
runtime (ftinit.c ft_default_modules) which modules got built at build
time. If there were a particularly better way to do that I don't think
there would be much difficulty adapting. For example if the whole
service / module structure went away and libfreetype just always did
what was built and the list of modules to be loaded at library init
didn't need to exist then we'd just build what bits we needed in each
build and drop the ftmodule.h customization bits.

> Some choices in FreeType, including the service and module infrastructure and
> very lean external dependencies, has helped it to spread so widely.
>
> > Other than that, the removal of RPATHs should be revisited. That's a
> > topic for another thread.
>
> Ok.
>
> Alexei
>

Re: Build system considerations

[Alexei Podtelezhnikov]

On Tue, May 19, 2020 at 8:09 AM Hugh McMaster  wrote:
> Is there any opportunity to avoid modifying ftoption.h directly to
> enable, say, subpixel rendering with a new build system? Carrying
> permanent patches for downstream packaging is annoying.

[Presently, FT_CONFIG_OPTION_SUBPIXEL_RENDERING only alternates
between ClearType and Harmony algorithms. Most users won't be able
to tell them apart.]

> Personally, I'd like to be able to enable various options via
> configure flags or a configurable file (JSON, anyone?) that's not a C
> header. Python could do nicely here.

One would think that modules.cfg is a configurable file like that but it turns
out that Chromium finds special ftmodule.h more convenient. We also have to
accommodate the less fortunate without Python on embedded systems.

Some choices in FreeType, including the service and module infrastructure and
very lean external dependencies, has helped it to spread so widely.

> Other than that, the removal of RPATHs should be revisited. That's a
> topic for another thread.

Ok.

Alexei

Re: Build system considerations

[Hugh McMaster]

On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote:
> > - Meson as the primary build system for FreeType developers, which
> >   includes the ability to run tests, sanitizers, coverage analysis,
> >   etc.
>
> It seems that Meson can create cmake package files, and probably build
> scripts, too.  Wouldn't that be the best solution?  I can also imagine
> that Meson builds `configure.ac`...

Is there any opportunity to avoid modifying ftoption.h directly to
enable, say, subpixel rendering with a new build system? Carrying
permanent patches for downstream packaging is annoying.

Personally, I'd like to be able to enable various options via
configure flags or a configurable file (JSON, anyone?) that's not a C
header. Python could do nicely here.

Other than that, the removal of RPATHs should be revisited. That's a
topic for another thread.

Re: Build system considerations

[Behdad Esfahbod]

Let me think about the HarfBuzz co-dependency a bit...

On Mon, May 18, 2020 at 12:26 PM Behdad Esfahbod  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  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
>> "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 

Re: Build system considerations

[Behdad Esfahbod]

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  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
> "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 

Re: Build system considerations

[Werner LEMBERG]

>> > In the end, and this is personal opinion, I find Meson cleaner than
>> > CMake,

I don't have to have a look at Meson to believe this immediately :-)

>> I'd vote for removing CMake support. Its inofficial status means that
>> people shouldn't rely on it anyway, even if there inevitably are
>> people that do.
>>
> I think providing a CMakeLists.txt that can be used directly to compile
> FreeType as a sub-project in a CMake-based project is still a very useful
> thing.

Yes.

> As well as a FindFreeType.cmake or FreeTypeConfig.cmake module to be
> installed to make the system library available.

Yes, too.

> - Meson as the primary build system for FreeType developers, which
>   includes the ability to run tests, sanitizers, coverage analysis,
>   etc.

It seems that Meson can create cmake package files, and probably build
scripts, too.  Wouldn't that be the best solution?  I can also imagine
that Meson builds `configure.ac`...


Werner

Re: Build system considerations

[Nikolaus Waxweiler]

Also note different optimisation levels. The make system uses -O2 by
default.

Re: Build system considerations

[Vincent Torri]

On Mon, May 18, 2020 at 8:44 AM David Turner  wrote:
>
>
>
> Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler  a écrit :
>>
>> First off: all of this sounds fantastic! I always love when stuff is deleted 
>> :)
>>
>> > In the end, and this is personal opinion, I find Meson cleaner than CMake,
>>
>> I'd vote for removing CMake support. Its inofficial status means that
>> people shouldn't rely on it anyway, even if there inevitably are
>> people that do.
>>
>
> I think providing a CMakeLists.txt that can be used directly to compile 
> FreeType as a sub-project in a CMake-based project is still a very useful 
> thing.
> As well as a FindFreeType.cmake or FreeTypeConfig.cmake module to be 
> installed to make the system library available.
>
> But that's just for the core library. I.e. the ability to build 
> documentation, install the library, or create distribution packages in CMake 
> are probably superfluous.
> I hope to see something like the following for the future:
>
> - Meson as the primary build system for FreeType developers, which includes 
> the ability to run tests, sanitizers, coverage analysis, etc.
> - Creating a distribution package should ensure the result supports 
> config/make and CMake out of the box to build a default configuration of the 
> library (with regards to features/modules, not external dependencies). The 
> meta-build script would be useful for this.
> - The distribution package should probably only contain what's needed to 
> build the library, and not all the extra tests we may use during development 
> (maybe we can separate them with git submodules, I don't know yet).
> - A developer that wants to use FreeType with a different module/feature 
> configuration would have to generate a new version of ftconfig.h/ftoption.h 
> and use that in his/her own build system.
>
> But as I said, baby steps, so let's not throw CMake support just yet.
>
> By the way, I've compared the size of the stripped libfreetype.so binaries 
> created by the 3 build systems:
>
> default: 712 KiB
> CMake: 812 KiB
> Meson: 896 KiB
>
> All generated on Linux from the same sources with the same ftconfig.h / 
> ftoption.h (in particular with all external dependencies enabled), and with 
> -fvisibility=hidden enabled for all of them.
> I don't understand why there is such a large differenc yet.

have you passed --strip to meson call ?
pass -v to ninja for verbose mode to see the differencies between make and ninja

regards

Vincent Torri

Re: Build system considerations

[David Turner]

Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler  a
écrit :

> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means that
> people shouldn't rely on it anyway, even if there inevitably are
> people that do.
>
>
I think providing a CMakeLists.txt that can be used directly to compile
FreeType as a sub-project in a CMake-based project is still a very useful
thing.
As well as a FindFreeType.cmake or FreeTypeConfig.cmake module to be
installed to make the system library available.

But that's just for the core library. I.e. the ability to build
documentation, install the library, or create distribution packages in
CMake are probably superfluous.
I hope to see something like the following for the future:

- Meson as the primary build system for FreeType developers, which includes
the ability to run tests, sanitizers, coverage analysis, etc.
- Creating a distribution package should ensure the result supports
config/make and CMake out of the box to build a default configuration of
the library (with regards to features/modules, not external dependencies).
The meta-build script would be useful for this.
- The distribution package should probably only contain what's needed to
build the library, and not all the extra tests we may use during
development (maybe we can separate them with git submodules, I don't know
yet).
- A developer that wants to use FreeType with a different module/feature
configuration would have to generate a new version of ftconfig.h/ftoption.h
and use that in his/her own build system.

But as I said, baby steps, so let's not throw CMake support just yet.

By the way, I've compared the size of the stripped libfreetype.so binaries
created by the 3 build systems:

default: 712 KiB
CMake: 812 KiB
Meson: 896 KiB

All generated on Linux from the same sources with the same ftconfig.h /
ftoption.h (in particular with all external dependencies enabled), and with
-fvisibility=hidden enabled for all of them.
I don't understand why there is such a large differenc yet.

Re: Build system considerations

[Timo Suoranta]

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
> 

Re: Build system considerations

[David Turner]

Le dim. 17 mai 2020 à 21:47, Nikolaus Waxweiler  a
écrit :

> First off: all of this sounds fantastic! I always love when stuff is
> deleted :)
>
> > In the end, and this is personal opinion, I find Meson cleaner than
> CMake,
>
> I'd vote for removing CMake support. Its inofficial status means that
> people shouldn't rely on it anyway, even if there inevitably are
> people that do.
>
> > - I would like to drop the dynamic module instantiation / lookup code
> from
> > the library, to simplify certain code paths.
>
> Has this ever been used by anyone?
>
> Yes, I did for a company I worked for a long time, then I rewrote an
open-source version of it (the PFR font driver).
But things are very different now,


> > - There are many things I'd like to get rid of, but apparently [cut off]
>
> ... yes? :D
>
> > - 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?
>
> This can probably only be answered by HarfBuzz people. I think Behdad
> is lurking here somewhere...
>

Re: Build system considerations

[Nikolaus Waxweiler]

First off: all of this sounds fantastic! I always love when stuff is deleted :)

> In the end, and this is personal opinion, I find Meson cleaner than CMake,

I'd vote for removing CMake support. Its inofficial status means that
people shouldn't rely on it anyway, even if there inevitably are
people that do.

> - I would like to drop the dynamic module instantiation / lookup code from
> the library, to simplify certain code paths.

Has this ever been used by anyone?

> - There are many things I'd like to get rid of, but apparently [cut off]

... yes? :D

> - 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?

This can probably only be answered by HarfBuzz people. I think Behdad
is lurking here somewhere...

Re: Build system considerations

[David Turner]

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
"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 

Re: Build system considerations

[Alexei Podtelezhnikov]

>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you could 
> please explain what's wrong with it so I can try to improve myself in the 
> future.

Rather easy. I am sure this is not how you communicate with people who
you barely know, say, in a supermarket or a scientific conference. We
all should strive to remain civil even when before you are in your
pajamas before you go to bed. When you are in front of your monitor,
you are in public.

Re: Build system considerations

[David Turner]

Le ven. 1 mai 2020 à 10:12, Albert Astals Cid  a écrit :

>
>
> I apologize if somebody felt personally wronged by my comment.
>
> Since I don't see anything wrong with it, I would be very happy if you
> could please explain what's wrong with it so I can try to improve myself in
> the future.
>
> Sure, "life bubble" is essentially a reference to the poster's private
life, which seems irrelevant here. "very biased" sounds judgemental, using
it in other contexts may be completely appropriate, but in this specific
one, looks like you may be trying to attack the poster's character instead
of the point he's trying to make.
That may not be what you tried to express, but I guarantee you that's how
it is perceived. It is likely that you misread Behdad's post (which was
*indeed* a bit ambiguous) and drew conclusions too quickly, assuming either
ill-intent or incompetence, but I encourage you to find better ways to
react to this kind of situation in the future.

Also don't worry too much about it, we all make mistakes, me included, and
the Internet is an unforgiving place where many of the bad decisions we
make on public lists are written in stone and searchable decades to come. I
hope you'll still be happy to contribute to the discussion after this :)

- David


> Best Regards,
>   Albert
>
>
>

Re: [Freetype-devel] Re: Build system considerations

[Werner LEMBERG]

> [...] I'm interested in the decision under a situation: if harfbuzz
> requires libstdc++, should we care the dependency of FreeType?

Please elaborate.  Given that FreeType is a C library it's not clear
to me why there should be an issue – FreeType happily works without
HarfBuzz (then with reduced capabilities, of course).


Werner

Re: Build system considerations

[Albert Astals Cid]

El divendres, 1 de maig de 2020, a les 0:52:16 CEST, David Turner va escriure:
> Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid  a écrit :
> 
> > El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va
> > escriure:
> > > Hi David,
> > >
> > > Thanks for bringing this up.  I come from the GNOME camp.  My
> > understanding
> > > is that meson is replacing autotools longterm, sidestepping attempts like
> > > cmake, the same way that git replaced CVS, sidestepping mercurial,
> > bazaar,
> > > etc.
> >
> > I am afraid that is your very biased life bubble.
> 
> I'm not sure you realize that what you wrote sounds insensitive and is
> bordering ad-hominen.
> You could have said that you disagree and that this doesn't match your
> experience for example.
> Instead you tone devalues the point you're trying to make.

I apologize if somebody felt personally wronged by my comment.

Since I don't see anything wrong with it, I would be very happy if you could 
please explain what's wrong with it so I can try to improve myself in the 
future.

Best Regards,
  Albert

Re: Build system considerations

[Keith Packard]

David Turner  writes:

> for ten different Unix-like system is a portability nightmare.
> On the other hand, building them for a standard Linux distribution, or OS
> X, is a well known problem, so we may consider keeping autotools/libtool as
> an escape hatch for esoteric systems that still exist, and use something
> simpler/better for Linux and OS X?

Mesa has two build systems currently (meson and scons). It's a struggle
keeping them in sync as the scons system is used by only a few
developers. Not ideal, but it can work if people using the minority
build system accept that it's up to them to keep it running.

-- 
-keith


signature.asc
Description: PGP signature

Re: Build system considerations

[Nikolaus Waxweiler]

> I'm not sure you realize that what you wrote sounds insensitive and is
> bordering ad-hominen.
> You could have said that you disagree and that this doesn't match your
> experience for example.
> Instead you tone devalues the point you're trying to make.

+1

> A) One of the major features of FreeType is that is can be easily built on
> many many systems (included embedded ones with weird toolchains), and it's
> something I'd like to keep for the core library.
>   In other words, I really want to keep the ability to compile an official
> release of FreeType with "./configure && make". That doesn't mean we have
> to use auto-tools or the current Make-based system though.
>   We may also consider providing CMake scripts to help use of FreeType
> releases into CMake-based projects.

There is a CMake build file already, it is for building a library and
maybe a package only though. Sometimes people try to build a
distribution package from it and run into problems...

>
> B) [...] choosing
> a solution that brings joy is more important than something that could
> support a team of 50 people working on it, or is industry standard.

+1 :)

I generally like the idea of having one nice primary build system and
supporting bare Makefiles for niche platforms.

> so we may consider keeping autotools/libtool as an escape hatch for esoteric 
> systems that still exist, and use something simpler/better for Linux and OS X?

I honestly wonder how many of those esoteric systems are still in use
and want to compile git master.

> Apart from that, it would be easy to write a script to generate the proper 
> compilation database

Ok :) I just thought it was neat that CMake can generate this
automatically during configure and my IDE will just pick it up.

Re: [Freetype-devel] Re: Build system considerations

[David Turner]

Le jeu. 30 avr. 2020 à 10:40, Nikolaus Waxweiler  a
écrit :

> One thing regarding build systems and IDE/tool integration:
>
> Cmake and others can generate a
> https://clang.llvm.org/docs/JSONCompilationDatawas a portabililty
> nightmarebase.html
>  that help
> tools like static analyzers and language servers and IDEs parse
> projects. It's very nice have when you hack on something.
>
> It also means that you have to have an entry for every single .c file,
> unless I'm missing something. FreeType bundles several .c files into
> bigger .c files, breaking the database. Werner mentioned that this is
> done because older compilers have worse inlining or dead code
> elimination or something like that. It would still be nice to have the
> database.
>
> The wrapper source files are used for two reasons:

1) Speed up compilation (though this is less of an issue with today's
powerful CPUs and multiple cores)

2) Much better / smaller generated machine code, because all FT_LOCAL
functions are really "static" and can be freely inlined by the simplest
compiler.
Getting the same level of optimization without wrappers requires
link-time-optimization (LTO), which may or may not be available depending
on the toolchain you're using, and cannot always be enabled by projects
embedding the library for multiple reasons (LTO is super slow, ThinLTO
makes it slightly better, but only if you use Clang, etc).

Apart from that, it would be easy to write a script to generate the proper
compilation database from the rules.mk/module.mk file with the patches I've
submitted to the mailing list (in another thread).
Also other tools can output such a database (e.g. GN has
--export-compile-commands=default for example, not sure about Meson).

Something to consider when cleaning up the build system :)
>
> 2020-04-30 9:11 GMT+01:00, suzuki toshiya :
> > The circular dependency is a headache, but I don't think the
> > reconsideration of the building system is good place to discuss
> > the simplification of the dependency between FreeType and harfbuzz.
> >
> > In my understanding, the features of harfbuzz used by FreeType are
> > very small subset, the classification of character encoding, script
> > and language. Although I sympathize with the circular dependency
> > problem, it would not be good idea to cloning them into FreeType
> > source code, because of the different time-frames between FreeType
> > and Unicode related features of harfbuzz (or Unicode itself).
> >
> > Some meta-building system would be the easiest way to avoid the
> > manual and repeated building of FreeType and harfbuzz, aslike some
> > GNU toolchains (binutils + gcc + gdb) ?
> >
> > Regards,
> > mpsuzuki
> >
> > P.S.
> > But, I'm interested in the decision under a situation: if harfbuzz
> > requires libstdc++, should we care the dependency of FreeType?
> >
> >
> > Vincent Torri wrote:
> >> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
> >>>
>  currently, to have harfbuzz support, freetype must be compiled
>  without hb support, then build hb with freetype support, then
>  freetype with hb.
> 
>  it would be nice to remove this circular dependency
> >>> AFAIK, this would only be possible by splitting either HarfBuzz or
> >>> FreeType into two packages, and this won't happen.
> >>
> >> or moving/coying some functions from freetype to hb, or conversely  ?
> >>
> >> Vincent Torri
> >>
> >>
> >
> >
>
>

Re: Build system considerations

[David Turner]

Le jeu. 30 avr. 2020 à 03:30, Alexei Podtelezhnikov  a
écrit :

> On Wed, Apr 29, 2020 at 8:34 PM David Turner  wrote:
> >
> > 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.
>
> Most serious projects I have encountered so far use ./configure; make.
> It is the libtool that annoys me. They refused to implement
> -fvisibiity=hidden  when I asked. They said that libtool was current
> when building shared libraries was hard, which is actually true. Let's
> just get rid of libtool as whatever it does for us is quite minimal.
>
> As far as I understand, libtool exists because building shared libraries
for ten different Unix-like system is a portability nightmare.
On the other hand, building them for a standard Linux distribution, or OS
X, is a well known problem, so we may consider keeping autotools/libtool as
an escape hatch for esoteric systems that still exist, and use something
simpler/better for Linux and OS X?


> Alexei
>

Re: Build system considerations

[David Turner]

Le jeu. 30 avr. 2020 à 23:33, Albert Astals Cid  a écrit :

> El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va
> escriure:
> > Hi David,
> >
> > Thanks for bringing this up.  I come from the GNOME camp.  My
> understanding
> > is that meson is replacing autotools longterm, sidestepping attempts like
> > cmake, the same way that git replaced CVS, sidestepping mercurial,
> bazaar,
> > etc.
>
> I am afraid that is your very biased life bubble.
>
> I'm not sure you realize that what you wrote sounds insensitive and is
bordering ad-hominen.
You could have said that you disagree and that this doesn't match your
experience for example.
Instead you tone devalues the point you're trying to make.


> CMake is the industry standard.
>
> I know comparisons are not easy, but let's search for "project" (a keyword
> my little knowledge of meson says that is present in all meson using
> projects) in meson files in github
> https://github.com/search?l=Meson=project=Code
> 6500 instances
>
> Now let's search for CMAKE_CXX_STANDARD a keyword in CMake used for C++
> projects (and not even mandatory to use)
> https://github.com/search?l=CMake=CMAKE_CXX_STANDARD=Code
> 246000 instances
>
> And that's not including the C based projects or similar.
>
> I know you don't have to choose build systems based on popularity, but
> saying that meson is sidestepping cmake is far from the truth.
>
>
I think Behdad was talking about the Gnome world here, not the rest of the
industry / open source community.
In all cases, I'm not a big fan of blindly following industry standards
just because they exist (*cough* JavaScript).

Just to clarify again for the context of this thread:

A) One of the major features of FreeType is that is can be easily built on
many many systems (included embedded ones with weird toolchains), and it's
something I'd like to keep for the core library.
  In other words, I really want to keep the ability to compile an official
release of FreeType with "./configure && make". That doesn't mean we have
to use auto-tools or the current Make-based system though.
  We may also consider providing CMake scripts to help use of FreeType
releases into CMake-based projects.

B) For people developing FreeType (instead of using it in their project),
it would be really useful to have a better build system to use. E.g. one
that allows building _and_ running tests easily, at a minimum.
I'd like to see easy support for cross-compilation, or even remote
cross-compilation (e.g. being able to automate a remote build on a Windows
or OS X machine through SSH is invaluable when doing cross-platform
development, as I have done that in the past), but these are minor compared
to the ability to run tests as soon as possible.
This second build system might be completely different from make/CMake,
and I don't care at all as long as we can support A) properly. Keep in mind
that FreeType has very few developers (which is perfectly ok), so choosing
a solution that brings joy is more important than something that could
support a team of 50 people working on it, or is industry standard.

I guess the best thing will be to experiment with several build systems to
see what they can offer. I'll try to setup something this week-end, but
feel free to contribute something so we can all check that.


Cheers,
>   Albert
>
> >
> > In the latest HarfBuzz release we added a meson build system.  Over the
> > next few months I expect us to remove our cmake one and eventually the
> > autotools one (which is the "official" one right now).
> >
> > Hope that helps,
> > behdad
> >
> > On Wed, Apr 29, 2020 at 5:34 PM David Turner  wrote:
> >
> > > 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 

Re: Build system considerations

[Albert Astals Cid]

El dijous, 30 d’abril de 2020, a les 19:35:19 CEST, Behdad Esfahbod va escriure:
> Hi David,
> 
> Thanks for bringing this up.  I come from the GNOME camp.  My understanding
> is that meson is replacing autotools longterm, sidestepping attempts like
> cmake, the same way that git replaced CVS, sidestepping mercurial, bazaar,
> etc.

I am afraid that is your very biased life bubble.

CMake is the industry standard.

I know comparisons are not easy, but let's search for "project" (a keyword my 
little knowledge of meson says that is present in all meson using projects) in 
meson files in github
https://github.com/search?l=Meson=project=Code
6500 instances

Now let's search for CMAKE_CXX_STANDARD a keyword in CMake used for C++ 
projects (and not even mandatory to use)
https://github.com/search?l=CMake=CMAKE_CXX_STANDARD=Code
246000 instances

And that's not including the C based projects or similar.

I know you don't have to choose build systems based on popularity, but saying 
that meson is sidestepping cmake is far from the truth.

Cheers,
  Albert

> 
> In the latest HarfBuzz release we added a meson build system.  Over the
> next few months I expect us to remove our cmake one and eventually the
> autotools one (which is the "official" one right now).
> 
> Hope that helps,
> behdad
> 
> On Wed, Apr 29, 2020 at 5:34 PM David Turner  wrote:
> 
> > 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
> >
> >
> 
> 

Re: Build system considerations

[Behdad Esfahbod]

Hi David,

Thanks for bringing this up.  I come from the GNOME camp.  My understanding
is that meson is replacing autotools longterm, sidestepping attempts like
cmake, the same way that git replaced CVS, sidestepping mercurial, bazaar,
etc.

In the latest HarfBuzz release we added a meson build system.  Over the
next few months I expect us to remove our cmake one and eventually the
autotools one (which is the "official" one right now).

Hope that helps,
behdad

On Wed, Apr 29, 2020 at 5:34 PM David Turner  wrote:

> 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/

Re: [Freetype-devel] Re: Build system considerations

[Nikolaus Waxweiler]

One thing regarding build systems and IDE/tool integration:

Cmake and others can generate a
https://clang.llvm.org/docs/JSONCompilationDatabase.html that help
tools like static analyzers and language servers and IDEs parse
projects. It's very nice have when you hack on something.

It also means that you have to have an entry for every single .c file,
unless I'm missing something. FreeType bundles several .c files into
bigger .c files, breaking the database. Werner mentioned that this is
done because older compilers have worse inlining or dead code
elimination or something like that. It would still be nice to have the
database.

Something to consider when cleaning up the build system :)

2020-04-30 9:11 GMT+01:00, suzuki toshiya :
> The circular dependency is a headache, but I don't think the
> reconsideration of the building system is good place to discuss
> the simplification of the dependency between FreeType and harfbuzz.
>
> In my understanding, the features of harfbuzz used by FreeType are
> very small subset, the classification of character encoding, script
> and language. Although I sympathize with the circular dependency
> problem, it would not be good idea to cloning them into FreeType
> source code, because of the different time-frames between FreeType
> and Unicode related features of harfbuzz (or Unicode itself).
>
> Some meta-building system would be the easiest way to avoid the
> manual and repeated building of FreeType and harfbuzz, aslike some
> GNU toolchains (binutils + gcc + gdb) ?
>
> Regards,
> mpsuzuki
>
> P.S.
> But, I'm interested in the decision under a situation: if harfbuzz
> requires libstdc++, should we care the dependency of FreeType?
>
>
> Vincent Torri wrote:
>> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
>>>
 currently, to have harfbuzz support, freetype must be compiled
 without hb support, then build hb with freetype support, then
 freetype with hb.

 it would be nice to remove this circular dependency
>>> AFAIK, this would only be possible by splitting either HarfBuzz or
>>> FreeType into two packages, and this won't happen.
>>
>> or moving/coying some functions from freetype to hb, or conversely  ?
>>
>> Vincent Torri
>>
>>
>
>

Re: [Freetype-devel] Re: Build system considerations

[suzuki toshiya]

The circular dependency is a headache, but I don't think the
reconsideration of the building system is good place to discuss
the simplification of the dependency between FreeType and harfbuzz.

In my understanding, the features of harfbuzz used by FreeType are
very small subset, the classification of character encoding, script
and language. Although I sympathize with the circular dependency
problem, it would not be good idea to cloning them into FreeType
source code, because of the different time-frames between FreeType
and Unicode related features of harfbuzz (or Unicode itself).

Some meta-building system would be the easiest way to avoid the
manual and repeated building of FreeType and harfbuzz, aslike some
GNU toolchains (binutils + gcc + gdb) ?

Regards,
mpsuzuki

P.S.
But, I'm interested in the decision under a situation: if harfbuzz
requires libstdc++, should we care the dependency of FreeType?


Vincent Torri wrote:
> On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
>>
>>> currently, to have harfbuzz support, freetype must be compiled
>>> without hb support, then build hb with freetype support, then
>>> freetype with hb.
>>>
>>> it would be nice to remove this circular dependency
>> AFAIK, this would only be possible by splitting either HarfBuzz or
>> FreeType into two packages, and this won't happen.
> 
> or moving/coying some functions from freetype to hb, or conversely  ?
> 
> Vincent Torri
> 
> 

Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 8:39 AM Werner LEMBERG  wrote:
>
>
> > currently, to have harfbuzz support, freetype must be compiled
> > without hb support, then build hb with freetype support, then
> > freetype with hb.
> >
> > it would be nice to remove this circular dependency
>
> AFAIK, this would only be possible by splitting either HarfBuzz or
> FreeType into two packages, and this won't happen.

or moving/coying some functions from freetype to hb, or conversely  ?

Vincent Torri

Re: Build system considerations

[Werner LEMBERG]

> currently, to have harfbuzz support, freetype must be compiled
> without hb support, then build hb with freetype support, then
> freetype with hb.
> 
> it would be nice to remove this circular dependency

AFAIK, this would only be possible by splitting either HarfBuzz or
FreeType into two packages, and this won't happen.


Werner

Re: Build system considerations

[Werner LEMBERG]

> Most serious projects I have encountered so far use ./configure;
> make.  It is the libtool that annoys me.  They refused to implement
> -fvisibiity=hidden when I asked.  They said that libtool was current
> when building shared libraries was hard, which is actually true.
> Let's just get rid of libtool as whatever it does for us is quite
> minimal.

Basically, I don't object.  It's a pity that libtool hasn't seen a new
release since five years.


Werner

Re: [Freetype-devel] Re: Build system considerations

[Keith Packard]

suzuki toshiya  writes:

> Is there any recommended alternative? Or, should we accept
> the "modern" situation where we have to execute twice to build
> shared and static libraries?

X and Mesa have switched to Meson, and I've used it in a couple of other
projects (including picolibc). On POSIX systems, it uses ninja (which is
a light-weight 'make' analog), which is a very fast build system. Mesa
compiles in much less time as a result.

And, yes, it supports building static and shared libraries at the same
time, and you can opt to make the static libraries PIC or non-PIC as you
please.

One huge advantage is that you program the build system in one language
(meson's native configuration language), which has a clear syntax and
consistent semantics. No more mixing m4, shell and make in a single
file. Plus, that means that it can generate output for a variety of
systems cleanly.

-- 
-keith


signature.asc
Description: PGP signature

Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 2:34 AM David Turner  wrote:
>
> Starting a thread here to discuss potential build system improvements for 
> FreeType.

currently, to have harfbuzz support, freetype must be compiled without
hb support, then build hb with freetype support, then freetype with
hb.

it would be nice to remove this circular dependency

regards

Vincent Torri

Re: Build system considerations

[Vincent Torri]

On Thu, Apr 30, 2020 at 2:34 AM David Turner  wrote:
>
> 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 prefer meson compared to cmake because :
 * more readable syntax (the main point for me)
 * meson honors CFLAGS/LDFLAGS
 * cross compilation is simpler

regards

Vincent Torri

Re: Build system considerations

[Werner LEMBERG]

> [...] 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 still favor autotools over cmake.  Especially the syntax of the
latter makes me cringe :-) On the other hand, we *do* have contributed
cmake support and some reports both for bugs and improvments in the
bug tracker for it.

And I haven't tried ninja or mason; this is lazyness on my side since
I'm not involved in any project that uses those build systems.

Whatever we do, I strongly believe that the build system using
autotools must stay.  Maybe we can enhance it by using automake...

Note that improvement of FreeType's build system is also a potential
GSoC project (see https://www.freetype.org/gsoc.html); this year there
was no proposal for that, however.


Werner

Re: [Freetype-devel] Re: Build system considerations

[Alexei Podtelezhnikov]

On Wed, Apr 29, 2020 at 10:17 PM suzuki toshiya
 wrote:
> It is a pity that I hear the lack of -fvisibility=hidden is
> not only current status but promised in the future release X-(.

Suzuki san,

We have -fvisibility=hidden despite libtool.

Alexei

Re: [Freetype-devel] Re: Build system considerations

[suzuki toshiya]

Dear Alexei, Turner,

It is a pity that I hear the lack of -fvisibility=hidden is
not only current status but promised in the future release X-(.

BTW, during the participation to Poppler and SVG Native Viewer,
I had big headache by the CMake's lack of the seamless (or
side-by-side) support for the shared and static libraries.

I feel similar impression with GN and Ninja combination,
from my small experience to build Chromium and Skia.

Is there any recommended alternative? Or, should we accept
the "modern" situation where we have to execute twice to build
shared and static libraries?

Regards,
mpsuzuki

P.S.
Welcome back Turner! I'm very happy to hear from you again!!



Alexei Podtelezhnikov wrote:
> On Wed, Apr 29, 2020 at 8:34 PM David Turner  wrote:
>> 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.
> 
> Most serious projects I have encountered so far use ./configure; make.
> It is the libtool that annoys me. They refused to implement
> -fvisibiity=hidden  when I asked. They said that libtool was current
> when building shared libraries was hard, which is actually true. Let's
> just get rid of libtool as whatever it does for us is quite minimal.
> 
> Alexei
> 
> 

Re: Build system considerations

[Alexei Podtelezhnikov]

On Wed, Apr 29, 2020 at 8:34 PM David Turner  wrote:
>
> 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.

Most serious projects I have encountered so far use ./configure; make.
It is the libtool that annoys me. They refused to implement
-fvisibiity=hidden  when I asked. They said that libtool was current
when building shared libraries was hard, which is actually true. Let's
just get rid of libtool as whatever it does for us is quite minimal.

Alexei

Build system considerations

[David Turner]

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