freetype-devel
[Top][All Lists]
Advanced

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



reply via email to

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