> 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? _______________________________________________ Freetype-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/freetype-devel
