Hello David,
> create mode 100644 include/freetype/config/compiler_macros.h
> create mode 100644 include/freetype/config/integer_types.h
> create mode 100644 include/freetype/config/mac_support.h
> create mode 100644 include/freetype/internal/compiler_macros.h
The same filename albeit in different folders might be confusing and
prone to errors.
Oh, very good point, I'll change this.
Also _macros.h is a bit redundant.
I don't think so, the header is really about defining macros that are compiler-specific.
How about
config/ftconfig-compiler.h and internal/ftcompiler.h?
First, we should avoid our cryptic short names now, the use of prefixes like "ft" was due to the fact that some people didn't even have proper directories when developing for embedded systems (a long long time ago).
So any public header began with "ft", all TrueType headers, began with "tt", etc... We really don't need this anymore. We need to keep the public header names consistent to avoid breaking all kinds of scripts that operate on them, but for anything new, or under internal/ or even src/, we are now free to rename everything to something vastly more meaningful.
The good thing is we don't have to do this all at once, progressively will be good.
Also ftconfig-compiler.h makes me think about a compiler for configuration files, I find "compiler_macros.h" or "compiler_defines.h" more explicit.
Personally, I
would rather reflect custody in the names: ftconfig-types.h
ftconfig-mac.h. It might just be me but I am not a big fan of
verbosity in C including filenames.
We should also decide whether to chose a dash or an underscore as the word separator for header and source file names :-)
I have no favorites here, but being consistent will be less ambiguous for everyone.
Alexei