[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Werner LEMBERG
Subject: Re: [ft-devel] Time for a new FreeType release
Date: Tue, 03 Apr 2018 07:57:04 +0200 (CEST)

>> The first is called "ANSI-specific configuration file", the second
>> "UNIX [...]".  Why are there two files?

The first one gets used without the `configure' script; it is generic
and should work on any platform.

>> The configure/Makefile system seems to always install the second on
>> Linux.  Why do we need the first then, for everything else?

Yes.  Not every OS uses (or can use) `configure'.

>> There are various #define differences between the two -- is
>> this... intended?


>> What would it take to unify the config.h files for all platforms?

This is not possible.  The idea of the `configure' script is to have a
template file `' that gets massaged to create `ftconfig.h'.
If we had a single `ftconfig.h' file we would still need a
UNIX-specific configuration file to be included by it.

> 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 during the process to make
> a tarball for releasing", I think it's very good idea.

Yes, probably.  On the other hand, it would disable direct compilation
from git for non-UNIX platforms, forcing people to first say `make
tarball' or something like this to generate the necessary file(s).

>> 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?

Exactly.  Those address@hidden@' variables are in

>> 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.

If we changed the FreeType build system to native automake, say, then
we could have a single `config.h' file.  I'm sometimes tempted to do


reply via email to

[Prev in Thread] Current Thread [Next in Thread]