Re: Build system considerations
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
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: [patch] Remove obsolete HAVE_STDINT_H probing
> It turns out the macro is never used, anad is never > included. Committed, thanks! Werner
Re: Odp: Re: The TrueType rendering accuracy nightmare
>> if you ask FontForge for B/W rasterization it uses FreeType in v35 >> mode. In other words, the rasterization results returned by >> FontForge in this case are *identical* to what ft2-demo returns. > > I happened to be cleaning up my github account lately - so I have an > up-to-date clone of fontforge repo. Fontforge uses freetype for the > hinting instruction debugging (i.e. like ttdbug), and when that's > on, set v35 for the instruction debugger. However, the > freetype-based hinting instruction debugging is optional, and > require source of freetype to be present at fontforge's build time. > Thus a non-custom build of fontforge does not ever call > FT_Property_Set, at all, as far as I can tell, because it is > commented out when there isn't a nearby source tree of freetype. Sorry for being imprecise. I was talking about the B/W rendering while using instruction debugger. > The optional hinting instruction debugger is the only place where > FT_Property_Set is used. Yep, I've added this :-) Werner
Re: Odp: Re: The TrueType rendering accuracy nightmare
On Monday, 18 May 2020, 05:30:58 GMT+1, Werner LEMBERG wrote: > if you ask FontForge for B/W rasterization it uses FreeType in v35 > mode. In other words, the rasterization results returned by FontForge > in this case are *identical* to what ft2-demo returns. Hi Werner, I happened to be cleaning up my github account lately - so I have an up-to-date clone of fontforge repo. Fontforge uses freetype for the hinting instruction debugging (i.e. like ttdbug), and when that's on, set v35 for the instruction debugger. However, the freetype-based hinting instruction debugging is optional, and require source of freetype to be present at fontforge's build time. Thus a non-custom build of fontforge does not ever call FT_Property_Set, at all, as far as I can tell, because it is commented out when there isn't a nearby source tree of freetype. The optional hinting instruction debugger is the only place where FT_Property_Set is used. Frank or George Williams might be able to give a more authoritative answer - but as far as I can see from fontforge's source code, its rendering behavior is not tunable in the manner of ft2-demos. Hin-Tak
Re: Patches to remove Jamfiles from freetype2 and freetype2-demos
> Here are two patches to remove the Jamrules/Jamfiles from the build > and documentation. Applied, thanks! Werner
Re: Logging Library-GSOC
> Also in the last message you said you would explore logging > libraries, and I would be curious about the results, i.e.: > > - Can you give one *concrete example* of an actual logging library > that would be useful for FreeType developers for development > purposes. Because I failed to find one. Investigating this is part of the GSoC project :-) > - What would be the actual benefits to using an external logging > library really? (a) We don't have to fiddle with OS-specific details. (b) Better control of log formatting. (c) Possibly a config file for (a) and/or (b) in addition to environment variables. > Note that the quality of the logging library(ies) has nothing to do > with this. I would rather not introduced a surperfluous dependency > to the build. As mentioned in another e-mail, it wouldn't be a dependency since it should be always statically linked. Werner
Re: Logging Library-GSOC
> I wanted to ask that after selecting desirable external library how > should I proceed: [For David T.: The idea is to statically link the library into FreeType using a git submodule. In other words, it's 'external' only because it is developed by other people.] > 1. Should I stick to the existing debugging facility in which >filtering of log messages is based on debug level comparisons of >various FreeType's components and only use the external library >to write log messages to file instead of stderr? Basically yes. As an improvement, I would like that the value of the `FT_COMPONENT` macro can be displayed optionally, e.g. [afhints] foo bar [ttgxvar] sproink ... The idea is that you first do a run with `FT2_DEBUG=any:7:labels` to see all those tags, then redo it with, say, FT2_DEBUG=afhints:7 to get only the 'afhints' debug messages if this is what you need for debugging. > 2. Most external libraries provide some log levels capabilities >themselves, so, should I think in direction of utilizing >those. In case yes, then how should that be utilized? Please elaborate and show examples. > In the 2nd case, FreeType's logger will completely depend on the > external library, and developers will also need to learn some new > information to use the logger. And In the worst-case scenario, if > the external library drops some functionality, we will need to make > amendments to the logger. I agree. > According to me, the 1st option is better since the experience of > using the logger will be the same for the client and developers and > the only dependency of FreeType on external library will be of > writing log messages to a file. Yep. Werner
Re: Build system considerations
>> > 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: Logging Library-GSOC
Hello David, Thanks for the response. *>What would be the actual benefits to using an external logging library really? The only thing I can think of is using structured debug messages (i.e. sending a (component, level, message) >tuple instead of a string to whatever receives the log messages, to allow better filtering). But we can easily refactor ftdebug.c to do that, with a default implementation that prints to stderr / , >and a debug-only API to inject a custom sink callback at runtime. Only then can we decide to optionally provide a sink that depends on a specific third-party library, as an option.* As far as I have understood the problem statement under this project @ https://www.freetype.org/gsoc.html is that the current logging capabilities of FreeType only print the logs on stderr and to scale the FreeType for multiple platforms where something similar to stderr don't exist, there is need to write the logs on files present on the file system. My queries were with respect to this use case. I am sorry I am unable to fully understand your concern in this regard. Can you please provide more insight on this? *>Can you give one concrete example of an actual logging library that would be useful for FreeType developers for development purposes. Because I failed to find one.* Regarding the library's exploration, it is still in progress and will keep you posted on the same. Some time back I explored zlog library and it was meeting some of our requirements but it was never finalized. Would like to hear from you on this? Also, if possible, can you please let me know which all libraries have already been explored and any documentation around this will help? Initially, we did discussed to change the ftdebug.c to write the logs on file system rather than using an external library but later we concluded that the external library will be more beneficial since they have matured and well tested APIs. *>Do you plan to improve the debugging macros used by FreeType. If so, how exactly?* I am still in the exploration phase and will plan the changes according to the external library... Thanks, Priyesh On Mon, May 18, 2020 at 3:46 PM David Turner wrote: > > > Le lun. 18 mai 2020 à 10:49, Priyesh kumar a > écrit : > >> Thanks for the reply... >> >> *>I recommend not baking details of the logging library into the rest of >> FreeType whenever possible. One thing that can be done is to send >> structured logs from FreeType, i.e. instead of >FT_Message() sending a >> string to whatever log, the function could instead send a (component, >> level, message) tuple, which would allow filtering externally (in the log >> library, through >whatever means are necessary). Also something useful when >> tracing is scoping traces with start/stop events, but that would require >> new FT_TRACE_XXX() macros, so should probably be >considered a stretch >> goal. Just keep this in mind if you intend to modify that part of the code.* >> Got that...will keep this in mind while exploring external logging >> libraries. >> >> *>I still don't know what the benefits of these external logging >> libraries will be. Can you clarify what are we supposed to gain from this >> in practical terms? Every dependency we add to the >library becomes a >> maintenance burden, so I would be in favor of the least coupling possible.* >> Yes, I agree that any new library adds to maintenance burden but we >> already had a discussion around this sometime back. The summary of the >> discussion was that a well maintained external library comes with mature >> API's and gets a lot of testing and hence that would be ideal to integrate. >> Please refer to this mail thread for details( >> https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html ) >> and let me know in case of any concern. >> >> I'm afraid, this thread doesn't seem to answer any of my concerns. Also > in the last message you said you would explore logging libraries, and I > would be curious about the results, i.e.: > > - Can you give one *concrete example* of an actual logging library that > would be useful for FreeType developers for development purposes. Because I > failed to find one. > > - What would be the actual benefits to using an external logging library > really? The only thing I can think of is using structured debug messages > (i.e. sending a (component, level, message) tuple instead of a string to > whatever receives the log messages, to allow better filtering). But we can > easily refactor ftdebug.c to do that, with a default implementation that > prints to stderr / , and a debug-only API to inject a custom sink callback > at runtime. Only then can we decide to optionally provide a sink that > depends on a specific third-party library, as an option. > > - Do you plan to improve the debugging macros used by FreeType. If so, how > exactly? > > Note that the quality of the logging library(ies) has nothing to do with > this. I would rather not introduced a surperfluous
Re: Build system considerations
Also note different optimisation levels. The make system uses -O2 by default.
Re: Logging Library-GSOC
Le lun. 18 mai 2020 à 10:49, Priyesh kumar a écrit : > Thanks for the reply... > > *>I recommend not baking details of the logging library into the rest of > FreeType whenever possible. One thing that can be done is to send > structured logs from FreeType, i.e. instead of >FT_Message() sending a > string to whatever log, the function could instead send a (component, > level, message) tuple, which would allow filtering externally (in the log > library, through >whatever means are necessary). Also something useful when > tracing is scoping traces with start/stop events, but that would require > new FT_TRACE_XXX() macros, so should probably be >considered a stretch > goal. Just keep this in mind if you intend to modify that part of the code.* > Got that...will keep this in mind while exploring external logging > libraries. > > *>I still don't know what the benefits of these external logging libraries > will be. Can you clarify what are we supposed to gain from this in > practical terms? Every dependency we add to the >library becomes a > maintenance burden, so I would be in favor of the least coupling possible.* > Yes, I agree that any new library adds to maintenance burden but we > already had a discussion around this sometime back. The summary of the > discussion was that a well maintained external library comes with mature > API's and gets a lot of testing and hence that would be ideal to integrate. > Please refer to this mail thread for details( > https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html ) > and let me know in case of any concern. > > I'm afraid, this thread doesn't seem to answer any of my concerns. Also in the last message you said you would explore logging libraries, and I would be curious about the results, i.e.: - Can you give one *concrete example* of an actual logging library that would be useful for FreeType developers for development purposes. Because I failed to find one. - What would be the actual benefits to using an external logging library really? The only thing I can think of is using structured debug messages (i.e. sending a (component, level, message) tuple instead of a string to whatever receives the log messages, to allow better filtering). But we can easily refactor ftdebug.c to do that, with a default implementation that prints to stderr / , and a debug-only API to inject a custom sink callback at runtime. Only then can we decide to optionally provide a sink that depends on a specific third-party library, as an option. - Do you plan to improve the debugging macros used by FreeType. If so, how exactly? Note that the quality of the logging library(ies) has nothing to do with this. I would rather not introduced a surperfluous dependency to the build. - David > Thanks, > Priyesh >
Re: Logging Library-GSOC
Thanks for the reply... *>I recommend not baking details of the logging library into the rest of FreeType whenever possible. One thing that can be done is to send structured logs from FreeType, i.e. instead of >FT_Message() sending a string to whatever log, the function could instead send a (component, level, message) tuple, which would allow filtering externally (in the log library, through >whatever means are necessary). Also something useful when tracing is scoping traces with start/stop events, but that would require new FT_TRACE_XXX() macros, so should probably be >considered a stretch goal. Just keep this in mind if you intend to modify that part of the code.* Got that...will keep this in mind while exploring external logging libraries. *>I still don't know what the benefits of these external logging libraries will be. Can you clarify what are we supposed to gain from this in practical terms? Every dependency we add to the >library becomes a maintenance burden, so I would be in favor of the least coupling possible.* Yes, I agree that any new library adds to maintenance burden but we already had a discussion around this sometime back. The summary of the discussion was that a well maintained external library comes with mature API's and gets a lot of testing and hence that would be ideal to integrate. Please refer to this mail thread for details( https://lists.nongnu.org/archive/html/freetype-devel/2020-02/msg00025.html ) and let me know in case of any concern. Thanks, Priyesh
Re: Build system considerations
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: Logging Library-GSOC
On Mon, May 18, 2020 at 9:28 AM David Turner wrote: > > > > Le lun. 18 mai 2020 à 09:03, Priyesh kumar a écrit : >> >> Hey, >> I wanted to ask that after selecting desirable external library how should I >> proceed: >> 1. Should I stick to the existing debugging facility in which filtering of >> log messages is based on debug level comparisons of various FreeType's >> components and only use the external library to write log messages to file >> instead of stderr? >> OR >> 2. Most external libraries provide some log levels capabilities themselves, >> so, should I think in direction of utilizing those. In case yes, then how >> should that be utilized? >> > I recommend not baking details of the logging library into the rest of > FreeType whenever possible. One thing that can be done is to send structured > logs from FreeType, i.e. instead of FT_Message() sending a string to whatever > log, the function could instead send a (component, level, message) tuple, > which would allow filtering externally (in the log library, through whatever > means are necessary). Also something useful when tracing is scoping traces > with start/stop events, but that would require new FT_TRACE_XXX() macros, so > should probably be considered a stretch goal. Just keep this in mind if you > intend to modify that part of the code. > >> >> In the 2nd case, FreeType's logger will completely depend on the external >> library, and developers will also need to learn some new information to use >> the logger. And In the worst-case scenario, if the external library drops >> some functionality, we will need to make amendments to the logger. >> > I still don't know what the benefits of these external logging libraries will > be. Can you clarify what are we supposed to gain from this in practical > terms? Every dependency we add to the library becomes a maintenance burden, > so I would be in favor of the least coupling possible. > what about dlopen this external log lib ? Vincent Torri
[patch] Remove obsolete HAVE_STDINT_H probing
It turns out the macro is never used, anad is never included.
From 3d9ce21da3fb4af2a90147ee513add6542808dcd Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 18 May 2020 09:33:38 +0200
Subject: [build] Remove obsolete HAVE_STDINT_H probing macro.
This macro was updated by the unix configure script and the
CMakeLists.txt one, but is never used in the source tree
(nor is included anywhere), so removing it entirely
should be safe.
---
CMakeLists.txt | 6 --
builds/unix/ftconfig.in | 1 -
2 files changed, 7 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index a7aec4d05..17787a171 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -240,7 +240,6 @@ endif ()
if (UNIX)
check_include_file("unistd.h" HAVE_UNISTD_H)
check_include_file("fcntl.h" HAVE_FCNTL_H)
- check_include_file("stdint.h" HAVE_STDINT_H)
file(READ "${PROJECT_SOURCE_DIR}/builds/unix/ftconfig.in"
FTCONFIG_H)
@@ -254,11 +253,6 @@ if (UNIX)
"#undef +(HAVE_FCNTL_H)" "#define \\1 1"
FTCONFIG_H "${FTCONFIG_H}")
endif ()
- if (HAVE_STDINT_H)
-string(REGEX REPLACE
- "#undef +(HAVE_STDINT_H)" "#define \\1 1"
- FTCONFIG_H "${FTCONFIG_H}")
- endif ()
string(REPLACE "/undef " "#undef "
FTCONFIG_H "${FTCONFIG_H}")
else ()
diff --git a/builds/unix/ftconfig.in b/builds/unix/ftconfig.in
index 7f3737776..a8c7d8acd 100644
--- a/builds/unix/ftconfig.in
+++ b/builds/unix/ftconfig.in
@@ -56,7 +56,6 @@ FT_BEGIN_HEADER
#undef HAVE_UNISTD_H
#undef HAVE_FCNTL_H
-#undef HAVE_STDINT_H
/* There are systems (like the Texas Instruments 'C54x) where a `char` */
/* has 16~bits. ANSI~C says that `sizeof(char)` is always~1. Since an */
--
2.20.1
Patches to remove Jamfiles from freetype2 and freetype2-demos
Here are two patches to remove the Jamrules/Jamfiles from the build and
documentation.
- David
From bfae69d8320e269975ba59f6293031242e9d7653 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Mon, 18 May 2020 09:16:12 +0200
Subject: [build] Remove Jamfile files from the tree.
These have not been used in a very very long time, so
better remove them. A corresponding patch will be submitted
to the freetype2-demos repository.
---
Jamfile| 224 -
Jamrules | 71 -
builds/unix/configure.raw | 4 -
devel/ftoption.h | 2 +-
include/freetype/config/ftoption.h | 2 +-
src/Jamfile| 19 ---
src/autofit/Jamfile| 53 ---
src/base/Jamfile | 90
src/bdf/Jamfile| 31
src/bzip2/Jamfile | 18 ---
src/cache/Jamfile | 37 -
src/cff/Jamfile| 36 -
src/cid/Jamfile| 34 -
src/gxvalid/Jamfile| 52 ---
src/gzip/Jamfile | 16 ---
src/lzw/Jamfile| 16 ---
src/otvalid/Jamfile| 37 -
src/pcf/Jamfile| 32 -
src/pfr/Jamfile| 35 -
src/psaux/Jamfile | 45 --
src/pshinter/Jamfile | 34 -
src/psnames/Jamfile| 31
src/raster/Jamfile | 32 -
src/sfnt/Jamfile | 42 --
src/smooth/Jamfile | 32 -
src/tools/Jamfile | 5 -
src/truetype/Jamfile | 37 -
src/type1/Jamfile | 35 -
src/type42/Jamfile | 32 -
src/winfonts/Jamfile | 16 ---
30 files changed, 2 insertions(+), 1148 deletions(-)
delete mode 100644 Jamfile
delete mode 100644 Jamrules
delete mode 100644 src/Jamfile
delete mode 100644 src/autofit/Jamfile
delete mode 100644 src/base/Jamfile
delete mode 100644 src/bdf/Jamfile
delete mode 100644 src/bzip2/Jamfile
delete mode 100644 src/cache/Jamfile
delete mode 100644 src/cff/Jamfile
delete mode 100644 src/cid/Jamfile
delete mode 100644 src/gxvalid/Jamfile
delete mode 100644 src/gzip/Jamfile
delete mode 100644 src/lzw/Jamfile
delete mode 100644 src/otvalid/Jamfile
delete mode 100644 src/pcf/Jamfile
delete mode 100644 src/pfr/Jamfile
delete mode 100644 src/psaux/Jamfile
delete mode 100644 src/pshinter/Jamfile
delete mode 100644 src/psnames/Jamfile
delete mode 100644 src/raster/Jamfile
delete mode 100644 src/sfnt/Jamfile
delete mode 100644 src/smooth/Jamfile
delete mode 100644 src/tools/Jamfile
delete mode 100644 src/truetype/Jamfile
delete mode 100644 src/type1/Jamfile
delete mode 100644 src/type42/Jamfile
delete mode 100644 src/winfonts/Jamfile
diff --git a/Jamfile b/Jamfile
deleted file mode 100644
index 76ccdeed0..0
--- a/Jamfile
+++ /dev/null
@@ -1,224 +0,0 @@
-# FreeType 2 top Jamfile.
-#
-# Copyright (C) 2001-2020 by
-# David Turner, Robert Wilhelm, and Werner Lemberg.
-#
-# This file is part of the FreeType project, and may only be used, modified,
-# and distributed under the terms of the FreeType project license,
-# LICENSE.TXT. By continuing to use, modify, or distribute this file you
-# indicate that you have read the license and understand and accept it
-# fully.
-
-
-# The HDRMACRO is already defined in FTJam and is used to add
-# the content of certain macros to the list of included header
-# files.
-#
-# We can compile FreeType 2 with classic Jam however thanks to
-# the following code
-#
-if ! $(JAM_TOOLSET)
-{
- rule HDRMACRO
- {
-# nothing
- }
-}
-
-
-# We need to invoke a SubDir rule if the FT2 source directory top is not the
-# current directory. This allows us to build FreeType 2 as part of a larger
-# project easily.
-#
-if $(FT2_TOP) != $(DOT)
-{
- SubDir FT2_TOP ;
-}
-
-
-# The following macros define the include directory, the source directory,
-# and the final library name (without library extensions). They can be
-# replaced by other definitions when the library is compiled as part of
-# a larger project.
-#
-
-# Name of FreeType include directory during compilation.
-# This is relative to FT2_TOP.
-#
-FT2_INCLUDE_DIR ?= include ;
-
-# Name of FreeType source directory during compilation.
-# This is relative to FT2_TOP.
-#
-FT2_SRC_DIR ?= src ;
-
-# Name of final library, without extension.
-#
-FT2_LIB ?= $(LIBPREFIX)freetype ;
-
-
-# Define FT2_BUILD_INCLUDE to point to your build-specific directory.
-# This is prepended to FT2_INCLUDE_DIR. It can be used to specify
-# the location of a custom which will point to custom
-# versions of `ftmodule.h' and `ftoption.h', for example.
-#
-FT2_BUILD_INCLUDE ?= ;
-
-# The list of modules to compile on any given build of the library.
-# By default, this will contain
Re: Logging Library-GSOC
Le lun. 18 mai 2020 à 09:03, Priyesh kumar a écrit : > Hey, > I wanted to ask that after selecting desirable external library how should > I proceed: > 1. Should I stick to the existing debugging facility in which filtering of > log messages is based on debug level comparisons of various FreeType's > components and only use the external library to write log messages to file > instead of stderr? > OR > 2. Most external libraries provide some log levels capabilities > themselves, so, should I think in direction of utilizing those. In case > yes, then how should that be utilized? > > I recommend not baking details of the logging library into the rest of FreeType whenever possible. One thing that can be done is to send structured logs from FreeType, i.e. instead of FT_Message() sending a string to whatever log, the function could instead send a (component, level, message) tuple, which would allow filtering externally (in the log library, through whatever means are necessary). Also something useful when tracing is scoping traces with start/stop events, but that would require new FT_TRACE_XXX() macros, so should probably be considered a stretch goal. Just keep this in mind if you intend to modify that part of the code. > In the 2nd case, FreeType's logger will completely depend on the external > library, and developers will also need to learn some new information to use > the logger. And In the worst-case scenario, if the external library drops > some functionality, we will need to make amendments to the logger. > > I still don't know what the benefits of these external logging libraries will be. Can you clarify what are we supposed to gain from this in practical terms? Every dependency we add to the library becomes a maintenance burden, so I would be in favor of the least coupling possible. According to me, the 1st option is better since the experience of using the > logger will be the same for the client and developers and the only > dependency of FreeType on external library will be of writing log messages > to a file. > > Please guide me... > Thanks > Priyesh > >
Re: Logging Library-GSOC
Hey, I wanted to ask that after selecting desirable external library how should I proceed: 1. Should I stick to the existing debugging facility in which filtering of log messages is based on debug level comparisons of various FreeType's components and only use the external library to write log messages to file instead of stderr? OR 2. Most external libraries provide some log levels capabilities themselves, so, should I think in direction of utilizing those. In case yes, then how should that be utilized? In the 2nd case, FreeType's logger will completely depend on the external library, and developers will also need to learn some new information to use the logger. And In the worst-case scenario, if the external library drops some functionality, we will need to make amendments to the logger. According to me, the 1st option is better since the experience of using the logger will be the same for the client and developers and the only dependency of FreeType on external library will be of writing log messages to a file. Please guide me... Thanks Priyesh
Re: [Freetype-devel] Re: GSOC - Distance Fields
Hello David, I took Alexei's advice and have already started writing the standalone implementation. You can check it out here: https://github.com/preversewharf45/freetype2-sdf. Thanks, Anuj On Mon, May 18, 2020, 12:20 PM David Turner wrote: > I agree with Alexei that it's probably a good idea to start writing a > prototype with whatever language / format you feel the more fluent first so > we can look at the algorithms and the outputted data. > This can later be rewritten into something more FreeType-specific (e.g. > fixed-floats are better than floats if you have simple ranges like > [-1.0..1.0] in general). > > - David > > Le mer. 13 mai 2020 à 16:59, Alexei Podtelezhnikov a > écrit : > >> On Wed, May 13, 2020 at 10:37 AM Anuj Verma >> wrote: >> > >> > > What do you need from FreeType to calculate DF? >> > > Do you see or know >> > where to find everything you need? >> > >> > I will need the bitmap and/or the outline depending upon the type of >> font. And yes I know where to find those. They both can be accessed from >> FT_Face. >> >> Great! Without further delay, go ahead and write a standalone program >> that calculates DF for a outline glyph in whatever format you choose >> or is appropriate. This is a lot of work by itself. How are you going >> to calculate it straight from Bezier outlines should concern you much >> more than memory issues. >> >> We can think about integrating it into FreeType ,once you have a >> standalone implementation. >> >> Alexei >> >>
Re: [Freetype-devel] Re: GSOC - Distance Fields
I agree with Alexei that it's probably a good idea to start writing a prototype with whatever language / format you feel the more fluent first so we can look at the algorithms and the outputted data. This can later be rewritten into something more FreeType-specific (e.g. fixed-floats are better than floats if you have simple ranges like [-1.0..1.0] in general). - David Le mer. 13 mai 2020 à 16:59, Alexei Podtelezhnikov a écrit : > On Wed, May 13, 2020 at 10:37 AM Anuj Verma wrote: > > > > > What do you need from FreeType to calculate DF? > > > Do you see or know > > where to find everything you need? > > > > I will need the bitmap and/or the outline depending upon the type of > font. And yes I know where to find those. They both can be accessed from > FT_Face. > > Great! Without further delay, go ahead and write a standalone program > that calculates DF for a outline glyph in whatever format you choose > or is appropriate. This is a lot of work by itself. How are you going > to calculate it straight from Bezier outlines should concern you much > more than memory issues. > > We can think about integrating it into FreeType ,once you have a > standalone implementation. > > Alexei > >
Re: Build system considerations
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.
