Re: [ft-devel] Time for a new FreeType release

[suzuki toshiya]

Dear Nikolaus,

Nikolaus Waxweiler wrote:
> The first is called "ANSI-specific configuration file", the second "UNIX 
> [...]". Why are there two files? The configure/Makefile system seems to 
> always install the second on Linux. Why do we need the first then, for 
> everything else? There are various #define differences between the two 
> -- is this... intended? What would it take to unify the config.h files 
> for all platforms?

When I entered freetype community, there were already 2 files,
so I don't know the original background. But I understand they
have their own rationales.

* POSIX C library has greater set of the features, than ANSI C,
although the majority of freetype users might be working with POSIX
environment.

* configrue (or cmake) is not always executable on the platforms
with ANSI C. sometimes the developers use strange & platform-specific
building tools, and they have to pick or edit the configuration files
manually. providing pre-configured config.h would be helpful for
these cases.

So I'm negative with the proposal to remove the pre-configured
files simply.

But, if you propose a workflow to reduce the maintenance cost, like,
"ftconfig.h for ANSI C platform should not be stored as self-standing
file in the git repository, because there is a possibility to be
overlooked in the maintenance. it should be generated automatically
from ftconfig.in during the process to make a tarball for releasing",
I think it's very good idea.

> Also, CMake comes with the configure_file() command[1], which 
> substitutes ${VAR} or @VAR@ with stuff or (un)defines things with 
> #cmakedefine. We can't really use it here because the ftconfig.* files 
> don't contain variables to expand. I guess because we aren't using the 
> (full) Autotools stack? I'd like to have one config.h for all platforms 
> that I can fill in from all build systems.

Sorry, I feel something like a tautology; if we drop all platforms
which building tool XXX does not support, we can support all systems
by building tool XXX.

> Also also, do we still need the macOS Framework stuff? Is it maybe 
> redundant in later versions?

If cmake is able to generate MPW configuration files, I'm interested in.
In fact, jam had once been expected to be useful for such - but it was
not. It's my long running homework to make a tool to update the MPW
configuration files automatically.

Regards,
mpsuzuki