Re: [freetype2] Remove #include FT_XXX_H includes from library sources
> And here's the patch to fix freetype2-demos compilation first. Applied too, thanks. Werner
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
> Thanks Werner, the patch looks good to me :-) OK, applied. Werner
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Thanks Werner, the patch looks good to me :-) Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit : > > Hello David, > > > > Since nobody does development on DOS or Windows 9x anymore, we can > > finally drop the requirement to use file names limited to the 8.3 > > format, which was the reason why the FT_LONG_HEADER_NAME_H macros > > were introduced in the first place. [...] > > Here's my patch, condensing your commits, adding some documentation, > and fixing some glitches. Please check! > > > - The public headers should not be renamed. > > What do you think about introducing a bunch of header files with long > names that do something like the following: > > file `FT_Multiple_Masters.h`: > > #include > /* EOF */ > > > Werner >
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Le lun. 8 juin 2020 à 13:37, Werner LEMBERG a écrit : > > Hello David, > > > > Since nobody does development on DOS or Windows 9x anymore, we can > > finally drop the requirement to use file names limited to the 8.3 > > format, which was the reason why the FT_LONG_HEADER_NAME_H macros > > were introduced in the first place. [...] > > Here's my patch, condensing your commits, adding some documentation, > and fixing some glitches. Please check! > > > - The public headers should not be renamed. > > What do you think about introducing a bunch of header files with long > names that do something like the following: > > file `FT_Multiple_Masters.h`: > > #include > /* EOF */ > > If this is about the public headers, why not, but let's do this in a future patch (with some documentation explaining what the new headers are, some simple sed or python scripts so developers can easily change the includes in their sources if they want to). Also, I would rather have include the new public header instead, it's cleaner, but I wonder if this is going to break scripts that try to list the headers explicitly in build systems or packaging scripts. As for the name, we should keep using format as part of the official source API, because it avoids a lot of needless conflicts to happen. On the other hand, we can use #include "ftmm.h" (instead of ) because this first search in the header's current directory. To be honest, I don't consider that a big priority for now, compared to the other build refactors / cleanups. It's easier not to do anything for now, to avoid breaking things unexpectedly for our users :-) > > Werner >
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Le mar. 9 juin 2020 à 01:06, Alexei Podtelezhnikov a écrit : > > >> We can remove as well, can't we? It is only used to > >> define the macros. So it is either ft2build.h and macros or neither. > > > > Not until all the consumers of FreeType are adapted to use direct > > header inclusion instead of the macros, > > Perhaps I was not clear. There is no point to have #include > in the FreeType source files that do not use macros any longer. The files > that use FT_CONFIG_OPTION_H still need it. > > But I do share the sentiment that it is probably too late for this kind of > change. The ship has sailed. > > I agree, we simply cannot change the source API at this point, which means we will need to support , the macros for the public headers, and *avoid* renaming the public headers themselves (because something is bound to break if we do). On the other hand, what we can do is: - Rename / move any internal header. Personally, I'm not too fond of CamelCase or Mixed_Camel_Case in header names :) - Stop using and the macros inside the FreeType sources (the patch is a first step in this direction). - If we deprecate a public API (e.g. I'm preparing patches to do that for FT_Add_Module() and related functions), they need to still be available and defined (as well as all types they depend on), but the implementation return FT_Err_Unimplemented_Feature. Of course, the doc should be updated with a "don't use this" message or something along that line. I would also like to get rid of ftmodule.h, and change the ftconfig.h file to only contain user-selectable options (it currently contains definitions that really belong to the implementation, and that nobody in its right mind would use in client code anyway), but this requires changing the way the library's features are configured, and that will probably happen after the module-API-deprecation anyway, or maybe after we change our primary build system. But none of that is urgent.
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
On 6/8/20 4:06 PM, Alexei Podtelezhnikov wrote: We can remove as well, can't we? It is only used to define the macros. So it is either ft2build.h and macros or neither. Not until all the consumers of FreeType are adapted to use direct header inclusion instead of the macros, Perhaps I was not clear. There is no point to have #include in the FreeType source files that do not use macros any longer. The files that use FT_CONFIG_OPTION_H still need it. Ah, yes I misunderstood you as saying to eliminate the file entirely - I agree that once the macros are not used then you can remove the #include directives for it from the other files in FreeType itself. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
>> We can remove as well, can't we? It is only used to >> define the macros. So it is either ft2build.h and macros or neither. > > Not until all the consumers of FreeType are adapted to use direct > header inclusion instead of the macros, Perhaps I was not clear. There is no point to have #include in the FreeType source files that do not use macros any longer. The files that use FT_CONFIG_OPTION_H still need it. But I do share the sentiment that it is probably too late for this kind of change. The ship has sailed.
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
On 6/8/20 5:59 AM, Alexei Podtelezhnikov wrote: On Mon, Jun 8, 2020 at 7:37 AM Werner LEMBERG wrote: Since nobody does development on DOS or Windows 9x anymore, we can finally drop the requirement to use file names limited to the 8.3 format, which was the reason why the FT_LONG_HEADER_NAME_H macros were introduced in the first place. [...] Here's my patch, condensing your commits, adding some documentation, and fixing some glitches. Please check! We can remove as well, can't we? It is only used to define the macros. So it is either ft2build.h and macros or neither. Not until all the consumers of FreeType are adapted to use direct header inclusion instead of the macros, which is likely to take years from the point you announce the macros are deprecated and that it's okay to use direct header names - especially those who were burned in the past by not using the macros when the headers got moved or renamed. In a few years you should be able to stop installing it by default, and only install if an option is specified to request it, much like is done for freetype-config today. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
On Mon, Jun 8, 2020 at 7:37 AM Werner LEMBERG wrote: > > Since nobody does development on DOS or Windows 9x anymore, we can > > finally drop the requirement to use file names limited to the 8.3 > > format, which was the reason why the FT_LONG_HEADER_NAME_H macros > > were introduced in the first place. [...] > > Here's my patch, condensing your commits, adding some documentation, > and fixing some glitches. Please check! We can remove as well, can't we? It is only used to define the macros. So it is either ft2build.h and macros or neither. The macros offer some flexibility of moving/renaming the files behind the scene, which will be lost.
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Hello David, > Since nobody does development on DOS or Windows 9x anymore, we can > finally drop the requirement to use file names limited to the 8.3 > format, which was the reason why the FT_LONG_HEADER_NAME_H macros > were introduced in the first place. [...] Here's my patch, condensing your commits, adding some documentation, and fixing some glitches. Please check! > - The public headers should not be renamed. What do you think about introducing a bunch of header files with long names that do something like the following: file `FT_Multiple_Masters.h`: #include /* EOF */ Werner 0001-Make-macros-for-header-file-names-optional.patch.xz Description: Binary data
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Le ven. 5 juin 2020 à 00:00, Werner LEMBERG a écrit : > > This is the first time ever that I got a git bundle to handle, and I'm > stuck. I don't know how to apply it to the git repository. Trying > > git pull freetype2-remove-macro-includes.bundle > > results in > > fatal: Couldn't find remote ref HEAD > > Ditto for `git fetch`. > > Please advise. > > No problem :-) there are several ways to use bundles (and I agree the documentation is lacking): 1) The easy way: use it as a git remote: $ git remote add bundle /path/to/bundle $ git fetch bundle >From /home/david/Downloads/freetype2-remove-macro-includes.bundle * [new branch] remove-macro-includes -> bundle/remove-macro-includes This is convenient because this fetches all the heads from the bundle at once, and gives you remote branches for all the heads in the bundle. 2) The hard way: git fetch /path/to/bundle Where is one of the references listed by "git bundle list-heads /path/to/bundle". For this specific bundle: $ git bundle list-heads ~/Downloads/freetype2-remove-macro-includes.bundle 2ebe58073a90538b64170fc274dc5530032726d8 refs/heads/remove-macro-includes So you could then try: $ git fetch ~/Downloads/freetype2-remove-macro-includes.bundle remove-macro-includes >From /home/david/Downloads/freetype2-remove-macro-includes.bundle * branchremove-macro-includes -> FETCH_HEAD Note that the fetch only creates FETCH_HEAD (which will be overwritten on a future fetch), so you don't have a label defined in your repository. You can create a branch from it easily with: $ git branch remove-macro-includes FETCH_HEAD Hope this helps. Let me know if you prefer a different format. I can probably attach patch files generated with "git format-patch" as well, but bundles are far more convenient and safe. - David PS: To create a bundle that includes all patches from origin/master to a local branch, use: $ git bundle create /path/to/new/bundle origin/master..my_branch This creates a head named "my_branch" in the bundle. > Werner >
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
Hello David, > This bundle contains patches to replace all #include FT_XXX_H > statements from the library into the corresponding #include > include. Thanks! If I understand you correctly, the idea is to 'normalize' FreeType so that it looks similar to other libraries, not alienating users with strange macros, right? > The bundle contains 88 commits. Each one renaming a single macro. I > recommend submitting the bundle squashed after verifying that > everything works, but I'll let you choose otherwise if you > prefer :-) This is the first time ever that I got a git bundle to handle, and I'm stuck. I don't know how to apply it to the git repository. Trying git pull freetype2-remove-macro-includes.bundle results in fatal: Couldn't find remote ref HEAD Ditto for `git fetch`. Please advise. Werner
Re: [freetype2] Remove #include FT_XXX_H includes from library sources
And here's the patch to fix freetype2-demos compilation first. Le jeu. 4 juin 2020 à 02:42, David Turner a écrit : > Since nobody does development on DOS or Windows 9x anymore, we can finally > drop the requirement to use file names limited to the 8.3 format, which was > the reason why the FT_LONG_HEADER_NAME_H macros were introduced in the > first place. > > This bundle contains patches to replace all #include FT_XXX_H statements > from the library into the corresponding #include > include. > > Note that: > > - This doesn't try to rename any file. > > - The macros are still defined by to avoid > breaking existing client codes. We will likely have to live with them for a > _very_ long time, but that's life. > > - A few configuration-related macros are kept (e.g. FT_CONFIG_CONFIG_H, > FT_MODULE_H) are kept intentionally. I'd like to get rid of FT_MODULE_H > entirely in the future by refactoring the way feature configuration is > performed, but that's for a very different time. > > - The public headers should not be renamed. On the other hand, anything > under include/freetype/internal/ might be renamed to clearer names in the > future. > > IMPORTANT: This currently breaks ftdiff.c in freetype2-demos because it > tries to include FT_INTERNAL_OBJECTS_H, this should be addressed by a > different patch. > > The bundle contains 88 commits. Each one renaming a single macro. I > recommend submitting the bundle squashed after verifying that everything > works, but I'll let you choose otherwise if you prefer :-) > > - David > From d6e2e57d08ab4c7db628be2ea8a01bc3ffc27482 Mon Sep 17 00:00:00 2001 From: David Turner Date: Thu, 4 Jun 2020 02:46:45 +0200 Subject: [build] Include internal headers by their real names. The FT_INTERNAL_XXX_H macros are going to disappear. --- mac/ftoldmac.c | 6 +++--- src/compos.c| 2 +- src/ftdiff.c| 4 ++-- src/ftdump.c| 6 +++--- src/ftgrid.c| 6 +++--- src/ftinspect/engine/engine.cpp | 4 ++-- src/ftvalid.c | 8 src/ftview.c| 6 +++--- 8 files changed, 21 insertions(+), 21 deletions(-) diff --git a/mac/ftoldmac.c b/mac/ftoldmac.c index 8b02f85..04a97c4 100644 --- a/mac/ftoldmac.c +++ b/mac/ftoldmac.c @@ -29,12 +29,12 @@ #include FT_TRUETYPE_IDS_H /* the following header shouldn't be used in normal programs */ -#include FT_INTERNAL_DEBUG_H +#include /* showing driver name */ #include FT_MODULE_H -#include FT_INTERNAL_OBJECTS_H -#include FT_INTERNAL_DRIVER_H +#include +#include /* FSSpec functions are deprecated since Mac OS X 10.4 */ #ifndef HAVE_FSSPEC diff --git a/src/compos.c b/src/compos.c index 1b76ae3..7d5d19c 100644 --- a/src/compos.c +++ b/src/compos.c @@ -17,7 +17,7 @@ #include #include FT_FREETYPE_H -#include FT_INTERNAL_GLYPH_LOADER_H +#include #include #include diff --git a/src/ftdiff.c b/src/ftdiff.c index c1c2e5e..0728714 100644 --- a/src/ftdiff.c +++ b/src/ftdiff.c @@ -24,8 +24,8 @@ /* showing driver name -- the two internal header files */ /* shouldn't be used in normal programs */ #include FT_MODULE_H -#include FT_INTERNAL_OBJECTS_H -#include FT_INTERNAL_DRIVER_H +#include +#include #include #include diff --git a/src/ftdump.c b/src/ftdump.c index b6f2b27..c3e277e 100644 --- a/src/ftdump.c +++ b/src/ftdump.c @@ -17,12 +17,12 @@ #include FT_MULTIPLE_MASTERS_H /* the following header shouldn't be used in normal programs */ -#include FT_INTERNAL_DEBUG_H +#include /* showing driver name */ #include FT_MODULE_H -#include FT_INTERNAL_OBJECTS_H -#include FT_INTERNAL_DRIVER_H +#include +#include /* error messages */ #undef FTERRORS_H_ diff --git a/src/ftgrid.c b/src/ftgrid.c index 29df45f..8a73bf2 100644 --- a/src/ftgrid.c +++ b/src/ftgrid.c @@ -20,12 +20,12 @@ #include /* the following header shouldn't be used in normal programs */ -#include FT_INTERNAL_DEBUG_H +#include /* showing driver name */ #include FT_MODULE_H -#include FT_INTERNAL_OBJECTS_H -#include FT_INTERNAL_DRIVER_H +#include +#include #include FT_STROKER_H #include FT_SYNTHESIS_H diff --git a/src/ftinspect/engine/engine.cpp b/src/ftinspect/engine/engine.cpp index b770846..d8bb903 100644 --- a/src/ftinspect/engine/engine.cpp +++ b/src/ftinspect/engine/engine.cpp @@ -13,8 +13,8 @@ #include FT_LCD_FILTER_H // internal FreeType header files; only available in the source code bundle -#include FT_INTERNAL_DRIVER_H -#include FT_INTERNAL_OBJECTS_H +#include +#include / diff --git a/src/ftvalid.c b/src/ftvalid.c index b4474ff..c8bae7d 100644 --- a/src/ftvalid.c +++ b/src/ftvalid.c @@ -26,10 +26,10 @@ #include FT_GX_VALIDATE_H /* the following four header files shouldn't be used in normal programs */ -#include FT_INTERNAL_DEBUG_H -#include FT_INTERNAL_VALIDATE_H -#include
