[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] Time for a new FreeType release
From: |
Nikolaus Waxweiler |
Subject: |
Re: [ft-devel] Time for a new FreeType release |
Date: |
Tue, 3 Apr 2018 10:40:20 +0100 |
> it should be generated automatically from ftconfig.in [...]
> The idea of the `configure' script is to have a template file `ftconfig.in'
> that gets massaged to create `ftconfig.h'.
This is what I want :) Currently, we have one .in for Unix and then
just spelt out ftconfig.h files for everything else... I'd like to
have ONE ftconfig.h.in for all/the majority of platforms with @STUFF@
that I can replace from CMake (best without regex hackery). Other
build systems could use the same file and replace things by
script/AC_CONFIG_FILES. The important piece is having just one
canonical template. Additionally, I'd like to have a ftoption.h.in
that I can also fill in from CMake without regexes.
So, let me rephrase the question: what would it take to unify all
ftconfig.* files into one ftconfig.h.in for all platforms?
> if we drop all platforms which building tool XXX does not support, we can
> support all systems by building tool XXX.
Don't get me wrong, I'm not saying we should drop unsupported-by-cmake
platforms (although I'm thinking that in my head, yes :B). Rather, I
want one canonical ftconfig.h.in and ftoption.h.in.
This reminds me: do we really need the devel/*.h files or can we make
something easier using build system hackery? Most of the defines can
be turned into build system options anyway, a debug build would be a
simple --enable-debug-build or something that turns everything on.
> MPW configuration files
What is MPW? Google brings up some m68k build scripts?
> FreeType needs simply #define'd configure file for obscure platforms without
> autotools or cmake.
There aren't too many things to be filled in from what I can gather;
if you port to obscure platforms, you can replace @STUFF@ by hand or
script quickly enough I suppose.
> 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).
Well, you want to invoke some build system anyway, so the build system
does the heavy lifting for you while building? Why ship pre-filled
config.hs?
> 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...
Why not use AC_CONFIG_FILES like in configure.raw?
- [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, 2018/04/03
- Re: [ft-devel] Time for a new FreeType release,
Nikolaus Waxweiler <=
- 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
- Re: [ft-devel] Time for a new FreeType release, Nikolaus Waxweiler, 2018/04/03