On Friday, 10 May 2024 at 09:03:52 BST, Werner LEMBERG <wl@gnu.org> wrote:
> > [...]
> >
> > But before that, we probably want to get ft2-demos having its own
> > ./configure (or cmake equivalent) first. It is a bit wierd that
> > detection of librsvg happens at freetype's configure (and freetype
> > itself has no use of librsvg), and CC= is also set there. I am a
> > little uncomfortable using c++ compiled freetype as my system library,
> > although c++ is a must for skia. (and svg-native-viewer too).
> This is due to historical circumstances; it was always intended to
> tightly couple the demo programs with the library.
> I wonder whether we should revert the old decision of moving the demo
> programs into a separate repository...
> > Last I heard somebody else was comtemplating getting freetype2-demos
> > its own ./confgure or equivalent?
> Yes, this would also be a possibility. Alas, no GSoC student was ever
> interested in overhauling FreeType's build system.
ttdebug is definitely one that needs freetype internals. But ftdump/ftview/ftgrid aren't using special / non-public APIs much?
To not break too much existing usages, it might be interesting to have an optionally created extra "override" makefile fragments that is loaded if it exists (created by another configure), to add some variables/options?
Hin-Tak