[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?
Yes.
>> 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 `ftconfig.in' 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 ftconfig.in 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
`builds/unix/{unix-cc.in,unix-def.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
that...
Werner
- [ft-devel] Time for a new FreeType release, Werner LEMBERG, 2018/04/01
- Re: [ft-devel] Time for a new FreeType release, Alexei Podtelezhnikov, 2018/04/02
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/02
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/02
- Message not available
- Re: [ft-devel] Time for a new FreeType release, suzuki toshiya, 2018/04/02
- Re: [ft-devel] Time for a new FreeType release,
Werner LEMBERG <=
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Werner LEMBERG, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Vincent Torri, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Vincent Torri, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Vincent Torri, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release, Vincent Torri, 2018/04/03