Le mar. 9 juin 2020 à 01:06, Alexei Podtelezhnikov <apodt...@gmail.com> a écrit :
> > >> We can remove <ft2build.h> 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 <ft2build.h> > 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 <ft2build.h>, 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 <ft2build.h> 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.
