Re: skeletal makefile for ftinspect (Re: Future of autotools)
On Fri, 14 Jul 2023 at 00:49, suzuki toshiya wrote: > > The pkg-config interface should take care of everything easily. Debian > and Ubuntu have the relevant qt5 pkg-config files. Other distributions > should too. > > Does pkg-config give the information for the pathname of moc? > (the original question by Hin-Tak was asking about the > appropriate path to use moc command) > > In my understanding, pkg-config is primarily designed to > provide the information to compile & link the libraries, > not designed to provide the information about the binary > executable commands. Extra information beyond the standard prefix, sysconfdir, libdir etc. is package dependent. In this case, Qt5Core.pc has a variable that provides the path to a directory containing binaries such as moc.
Re: skeletal makefile for ftinspect (Re: Future of autotools)
On Thu, 13 Jul 2023 at 14:20, suzuki toshiya wrote: > I would try to let AX_HAVE_QT() macro to find appropriate set: > > https://www.gnu.org/software/autoconf-archive/ax_have_qt.html > > In the case of Debian (and Ubuntu), qtchooser might be the unified > interface to switch 4, 5, and maybe 6 in future. It seems that > AX_HAVE_QT() does not check it, because the last update of AX_HAVE_QT > was 2014 X-p. > The pkg-config interface should take care of everything easily. Debian and Ubuntu have the relevant qt5 pkg-config files. Other distributions should too.
Re: Future of autotools
On Tue, 11 Jul 2023 at 19:26, suzuki toshiya wrote: > Hi, > > In the conventional workflow, the source tree of the FreeType2 library > has "./configure", but freetype-demos does not have. Just starting > "make" with existing Makefile under "freetype-demos" carries the > configured values from freetype directory. If we are going to overhaul the build system, I’ve long wanted to have FreeType demos build as a separate package that links against a system-installed FreeType library (not the source directory). I know the demos are intended to be used with the same version of FreeType, so it could be a build dependency requirement to link against the same version. This would avoid users linking against older versions. The meson for the ftinspect > wants to confirm additional libraries, like Qt5 (you can find the > declaration of the dependency in src/ftinspect/meson.build). > > If somebody wants to try to make autotools to support the building > of Qt5-based ftinspect, new configure should be added to freetype-demos, > to check the availability of the extra libraries for ftinspect? > Or, such check should be added to existing freetype/configure, even > if libfreetype itself has no dependency with them? > That’s how we detect python3 and librsvg (although I wish there were a lighter library available). That said, there’s certainly an argument for alternative approaches. > Regards, > mpsuzuki >
Re: Future of autotools
Hi Werner, On Tue, 11 Jul 2023 at 02:10, Werner LEMBERG wrote: > > >> If ftinspect and, potentially, other software is not going to be > >> built via autotools, is there a case to move to another build > >> system? > > Well, yes. Meson will eventually become the main tool for building > FreeType, I think (or rather, it definitely won't become CMake as the > default). This is good to know. I’ll start experimenting with meson to build the Debian packages before making the switch. However, cleaning up the build system was/is a GSoC > project, so nobody else touched it in earnest. In particular, I am > not a specialist for Meson; additionally, Meson itself is still quite > a moving target. > What functionality are you looking for? From my limited experience of meson, it’s a bit clunky to get working, but once I’ve got the correct commands everything seems to build correctly. Hugh
Future of autotools
I've been preparing an update to the Debian package of FreeType and realised ftinspect is limited to the meson build system only. Debian, by default, has always used autotools. There are three build systems currently available for use in FreeType: autotools, cmake and meson. As I understand past discussions, autotools is the default (and fully supported). If ftinspect and, potentially, other software is not going to be built via autotools, is there a case to move to another build system? Hugh
Re: Need help compiling freetype demos
On Wed, 10 May 2023 at 10:48, Craig White wrote: > > I am trying to compile the freetype demo programs using meson, and I get this > linker error: > https://hastebin.com/share/utuhanafik.bash > it appears to be complaining about cairo. I am running ubuntu 22 LTS and > have the latest "libcairo2-dev" installed. How can I fix this? Did you set the `--prefix` option when running `meson setup`? Your build system is include /local/ in some paths, which is incorrect for Debian-based systems. >From the fourth line of your log: /usr/local/lib/x86_64-linux-gnu/libpng16.so --> incorrect /usr/lib/x86_64-linux-gnu/librsvg-2.so --> correct
Re: Compiling old version (2.6.5) of FreeType
Hi Anurag, On Thu, 1 Sept 2022 at 18:51, Anurag Thakur wrote: > > Hello Werner, Alexei > > I tried compiling FreeType version 2.6.5 to benchmark it against the current > `master`, but faced some issues since it is a pretty old version. > > I checked out the VER-2-6-5 tag on the repo and ran autogen.sh, which > resulted in: > > > generating `configure.ac' > running `aclocal -I . --force' > running `libtoolize --force --copy --install' > libtoolize: putting auxiliary files in '.'. > libtoolize: copying file './config.guess' > libtoolize: copying file './config.sub' > libtoolize: copying file './install-sh' > libtoolize: copying file './ltmain.sh' > libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac, > libtoolize: and rerunning libtoolize and aclocal. > libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am. > running `autoconf --force' > configure.ac:99: warning: The macro `AC_HEADER_STDC' is obsolete. > configure.ac:99: You should run autoupdate. > ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from... > configure.ac:99: the top level These are just informational warnings about using old autoconf macros. Nothing to worry about. > Simply running configure and make seemed to work but then there were > compilation errors in freetype-demos. How are you compiling? You need to use a chroot or similar container. Otherwise, FreeType will #include the modern FreeType headers installed via your distro's development package (e.g. libfreetype-dev or similar), causing build failures. > I tried checking out a ~2016 commit but couldn't really get it to compile. > > > Version 2.6.5 is important because the original font-rs post is from 2016, > which used 2.6.5 as the benchmark for comparison. > > The aim is to run FreeType 2.6.5 for benchmarking. Any help regarding this > would be appreciated. > > Regards, > Anurag
Licence attribution of new meson python scripts
Hi all, I'm updating Debian's copyright file for FreeType 2.10.4. Whose name should be attributed for copyright of the python scripts in builds/meson? The files have no copyright notation, but were created by David. In saying that, most other files are copyright David Turner, Robert Wilhelm and Werner Lemberg, so just wondering how to attribute here. Thanks, Hugh
Re: Vulnerability warning (CVE-2020-15999)
Hi Werner, On Tue, 20 Oct 2020 at 09:07, Werner LEMBERG wrote: > > I've just fixed a heap buffer overflow that can happen for some > malformed `.ttf` files with PNG sbit glyphs. It seems that this > vulnerability gets already actively used in the wild, so I ask all > users to apply the corresponding commit as soon as possible. > > Tomorrow I will do a 2.10.4 release. Does this vulnerability affect older (< 2.10.3) versions of FreeType as well? >
woff2tags.h copyright date
I've been running copyright checks for Debian, and came across src/sfnt/woff2tags.h. The copyright statement lists 1996-2020. Can I just check why this 1996 is the starting date, instead of 2019, when the file was created? Thanks, Hugh
Re: Build system considerations
On Mon, 18 May 2020 at 23:59, Werner LEMBERG wrote: > > - Meson as the primary build system for FreeType developers, which > > includes the ability to run tests, sanitizers, coverage analysis, > > etc. > > It seems that Meson can create cmake package files, and probably build > scripts, too. Wouldn't that be the best solution? I can also imagine > that Meson builds `configure.ac`... Is there any opportunity to avoid modifying ftoption.h directly to enable, say, subpixel rendering with a new build system? Carrying permanent patches for downstream packaging is annoying. Personally, I'd like to be able to enable various options via configure flags or a configurable file (JSON, anyone?) that's not a C header. Python could do nicely here. Other than that, the removal of RPATHs should be revisited. That's a topic for another thread.
Re: new version soon
On Fri, 8 May 2020 at 22:27, Alexei Podtelezhnikov wrote: > > On Fri, May 8, 2020 at 8:10 AM Hugh McMaster wrote: > > Please package rasterinfo.html in ft2docs. It's been missing for > > several releases now. > > Do you mean > https://www.freetype.org/freetype2/docs/rasterinfo/rasterinfo.html ? > I do not think RasterInfo.ttf was ever considered a part of FreeType. Yes, that's what I was referring to. If not included, the packaged documentation is left with a broken section. I was never sure if this was a mistake or a deliberate omission. Ideally, that section should be removed before packaging if it's not supposed to be there. But why have it in the online version then?
Re: new version soon
Hi Werner, On Fri, 8 May 2020 at 18:37, Werner LEMBERG wrote: > I'm cutting a new version today or tomorrow. Any last urgent things > to consider? Please package rasterinfo.html in ft2docs. It's been missing for several releases now. Thank you, Hugh
Re: commit 6a92b1fad makes FreeType reject woff files
On Thu, 27 Feb 2020 at 15:35, Moazin Khatri wrote: > As a temporary solution, is there a reason not to go for 1? > AFAIK, a devel build already requires all dependencies to > be installed so it shouldn't hurt to require an installation > of zlib too. Out of interest, why does FreeType still embed zlib? It's old, and building against a system version is better. Hugh
