Looks like that value is defined or not based on a configure-time option in Fontconfig. Pango either (a) should not be using -Werror=undef, or (b) should check that it's defined before using it: #if defined(TT_CONFIG_OPTION_SUBPIXEL_HINTING) && (TT_CONFIG_OPTION_SUBPIXEL_HINTING & 2).

Possible workaround would be to add autogenargs="-Wnoerror=undef" to the moduleset, does that work?

I don't know how to do this to check if it works. Please tell me.

Looks like Emmanuele has fixed it:

https://git.gnome.org/browse/pango/commit/?id=0b86506c7c19e3ef0c6581dfbc04aec769af57c3
https://git.gnome.org/browse/pango/commit/?id=148a5af3f66b504d3d36df3c6c45f218250a8a0a

Nope... hey Emmanuele, it looks like tests are still broken, do you want to fix that too?

E.g.:

In file included from /usr/include/freetype2/freetype/config/ftconfig-64.h:42:0,
                 from /usr/include/freetype2/freetype/config/ftconfig.h:9,
                 from /usr/include/freetype2/freetype/freetype.h:33,
                 from ../../../../Projects/GNOME/pango/pango/pangofc-font.h:34,
                 from ../../../../Projects/GNOME/pango/pango/pango-ot.h:27,
                 from ../../../../Projects/GNOME/pango/tests/test-ot-tags.c:24:
/usr/include/freetype2/freetype/config/ftoption.h:845:5: error: "TT_CONFIG_OPTION_SUBPIXEL_HINTING" is not defined [-Werror=undef]
 #if TT_CONFIG_OPTION_SUBPIXEL_HINTING & 1
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/freetype2/freetype/config/ftoption.h:849:5: error: "TT_CONFIG_OPTION_SUBPIXEL_HINTING" is not defined [-Werror=undef]
 #if TT_CONFIG_OPTION_SUBPIXEL_HINTING & 2
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

I tried adding '-DPANGO_COMPILATION' to test_cflags in tests/meson.build, but that didn't help. I don't understand why. It is frustrating.

`PANGO_COMPILATION` won't do anything about it: it's a bug in freetype2. Freetype checks the value of a pre-processor macro that may not be defined, which is caught by -Werror=undef in Pango.

This issue has been fixed in freetype 2.8, which has been released in May 2017. Instead of playing whack-a-mole with a fixed upstream bug, Jhbuild should probably start building freetype from Git or tarball, and not defined it as a system dependency.

Created attachment 353457 [details] [review]
core-deps-3.26: Build freetype2 from tarball

Versions prior 2.8 have a bug in the ft-config.h header that trips
everything building with `-Wundef`. The new 2.8 release of freetype
fixes this issue.

This should fix the issue on older distributions still shipping freetype < 2.8.

Attachment 353457 [details] pushed as f140a3b - core-deps-3.26: Build freetype2 from tarball

(In reply to Emmanuele Bassi (:ebassi) from comment #6)
> `PANGO_COMPILATION` won't do anything about it: it's a bug in freetype2.
> Freetype checks the value of a pre-processor macro that may not be defined,
> which is caught by -Werror=undef in Pango.

Well PANGO_COMPILATION is what you used to suppress the -Werror=undef....

Anyway, this solution is fine too; thanks!

mcatanzaro:  ebassi: Even after my extra patches in https://bugzilla.gnome.org/show_bug.cgi?id=783179, JHBuild is still not building freetype2 before pango. I can't figure out why. There does not seem to be any dependency cycle.
mcatanzaro stumped
ebassi[m]:  mcatanzaro: No idea. It should be built.
mcatanzaro:  It should be... but it's not....
mcatanzaro:  ebassi[m]: OK, it's not even built when I 'jhbuild build freetype2'. It just builds up to harfbuzz and then quits.
mcatanzaro:  ebassi[m]: 'jhbuild update freetype2' downloads tarballs up to harfbuzz then quits. But 'jhbuild updateone freetype2' works.
mcatanzaro:  Also, 'jhbuild buildone freetype2' works
mcatanzaro:  Something is wrong in the dependency computation

The following fix has been pushed:
5e85759 3.26: Always build freetype2

Created attachment 354740 [details] [review]
3.26: Always build freetype2

We are trying to figure out why freetype2 is not being built. It's
supposed to be built if the system version is less than 2.8.0. But
that's not working properly for some reason. So always build it instead.

(In reply to Michael Catanzaro from comment #12)
> The following fix has been pushed:
> 5e85759 3.26: Always build freetype2

I wound up reverting this because harfbuzz depends on freetype, so freetype has to be built first for the harfbuzz build to succeed. But freetype depends on harfbuzz, so we have a bootstrapping problem. jhbuild doesn't have any good way to handle this so we'll need to rely on distros to build freetype for us.

I've worked around that in Gtk-OSX by having two modules, freetype-no-harfbuzz and freetype. The first includes --no-harfbuzz in autogenargs and builds enough of freetype that harfbuzz is happy. Freetype depends on harfbuzz and harfbuzz on freetype-no-harfbuzz.

(In reply to Michael Catanzaro from comment #14)
> I wound up reverting this because harfbuzz depends on freetype, so freetype
> has to be built first for the harfbuzz build to succeed. But freetype
> depends on harfbuzz, so we have a bootstrapping problem. jhbuild doesn't
> have any good way to handle this so we'll need to rely on distros to build
> freetype for us.

And, for whatever reason, pango is still building fine. So I am going to leave it like this. If we have problems with pango again then we will need to use the reverse solution: demote harfbuzz to a sysdep, put freetype 2.8 in core-deps, and have freetype depend on harfbuzz instead of vice-versa.

John's solution would also work if the sysdep approach fails, but we don't currently have any such bootstrap modules and it'd be nice to avoid adding one. It's also just generally preferable to have more sysdeps and fewer core-deps to have to build.