configure --enable-pango no longer works

[Manolo]

As of git push edd5818, support of Pango obtained with

option --enable-pango of the configure command no longer works.

Please, notice that the FLTK code is also expected to allow

./configure --enable-x11 --enable-pango

when run under macOS.

Pango option still works for CMake-based builds.

[Albrecht Schlosser]

On 2/15/21 12:29 PM Manolo wrote:
>
> As of git push edd5818, support of Pango obtained with
> option --enable-pango of the configure command no longer works.

Fixed in a355c16971, certainly for Linux...

> Please, notice that the FLTK code is also expected to allow
> ./configure --enable-x11 --enable-pango
> when run under macOS.

I can't test this (yet). Please confirm whether it works (or not).

[Manolo]

On Tuesday, February 16, 2021 at 1:56:31 PM UTC+1 Albrecht Schlosser wrote:

On 2/15/21 12:29 PM Manolo wrote:
>
> As of git push edd5818, support of Pango obtained with
> option --enable-pango of the configure command no longer works.

Fixed in a355c16971, certainly for Linux...

Yes, indeed.

> Please, notice that the FLTK code is also expected to allow
> ./configure --enable-x11 --enable-pango
> when run under macOS.

I can't test this (yet). Please confirm whether it works (or not).

and it works also under macOS.

Many thanks for this fix.

I still don't grasp clearly the new autoconf syntax, therefore I wonder what happens

when pkg-config is present on the system and when commands such as

     pkg-config --cflags pangoxft

and

     pkg-config --libs pangoxft

run correctly.

The previous code would use information returned by these commands to populate

the CXFLAGS and LDFLAGS. Therefore, statements such as this one :

                CXXFLAGS="-I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include $CXXFLAGS"
would not be used when pkg-config has successfully run.

The benefit of that is that configure.ac becomes independent from hardwired paths.

Hardwired paths are used only in the absence of pkg-config.

Does the new code in file configure.ac follow this logic too?

[Albrecht Schlosser]

On 2/16/21 4:56 PM Manolo wrote:
>
> I still don't grasp clearly the new autoconf syntax, therefore I wonder
> what happens
> when pkg-config is present on the system and when commands such as
>      pkg-config --cflags pangoxft
> and
>      pkg-config --libs pangoxft
> run correctly.
> The previous code would use information returned by these commands to
> populate the CXFLAGS and LDFLAGS.

> ...

> The benefit of that is that configure.ac becomes independent from
> hardwired paths.
> Hardwired paths are used only in the absence of pkg-config.
>
> Does the new code in file configure.ac follow this logic too?

No, not really. My fix of the (broken) code was not correct. If
pkg-config was available it would execute both parts, i.e. it would add
libs found by pkg-config *and* the "default" libs (and CXXFLAGS)
hardcoded in the second part.

Honestly, I don't think that we can rely on that second part with
hardcoded libs and flags anymore. I tried it by "disabling" the first
(pkg-config) part for pango detection and the build failed.

Then I tried to update the 2nd part with the libs *my* system needs (by
looking at the output of pkg-config) and the result was a pretty long
list of libs and flags, much longer than before. See attached patch
which I don't want to commit yet...

Can you please test the patch?

You need to know:

To activate the patch you need to force autoconf to create a new
configure file. My test command line is:

$ make distclean; autoconf -f ; ./configure --enable-pango; make -j9 &&
test/editor misc/lorem_ipsum.txt

This opens the editor and shows if pango works.

You can also take a look at the configure output.

Mods in configure.ac:

Line 1095/96:

# AS_IF([test x$PKGCONFIG != x], [
AS_IF([test x$PKGCONFIG = xxx], [

The first (original) line is commented out, the second line *disables*
the path where pkg-config is used. You can re-enable the first part by
just moving the '#' to the other line.

The patched version prints some debug statements starting with:

* * * ...

Before committing my changes we'd need to remove the debug statements.

This modified version should fall back to the "default" libs and flags
but I suspect that this is no longer useful (if it ever was). We rely on
pkg-config anyway for "--enable-xft" although there's maybe a working
fallback or something like that.

So, while the patch would correct the logic I don't think that it would
fix the fallback mechanism for any current system.

My take on this is that we should remove the fallback and rely entirely
on pkg-config, at least WRT finding pango.

Last but not least: my configure output with this patch as far as it is
related to pango:

configure: * * * '--enable-pango' : using system-defaults * * *
configure: * * * LIBS = -lpangoxft-1.0 -lpangoft2-1.0 -lfontconfig
-lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo
-lXft -lfontconfig -lXinerama -pthread -lpthread -ldl -lm -lX11 * * *
configure: * * * CXXFLAGS = -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/harfbuzz
-I/usr/include/cairo -I/usr/include/uuid -I/usr/include/freetype2
-I/usr/include/libpng16 * * *
checking pango/pango.h usability... yes
checking pango/pango.h presence... yes
checking for pango/pango.h... yes
checking for pango_layout_new in -lpango-1.0... yes
checking for pango_xft_render_layout in -lpangoxft-1.0... yes
checking pango/pangoxft.h usability... yes
checking pango/pangoxft.h presence... yes
checking for pango/pangoxft.h... yes
checking for pango_layout_new in -lpango-1.0... (cached) yes
checking for pango_xft_render_layout in -lpangoxft-1.0... (cached) yes

[Manolo]

Albrecht: Here is the result of my test of patch pango.diff. It doesn't work :=(

I tested on macOS to try something different than another Debian-based Linux.

rm configure

[biomp2:~/Documents/fltk/fltk-git] % patch -p1<pango.diff
patching file configure.ac
[biomp2:~/Documents/fltk/fltk-git] % autoconf -f
[biomp2:~/Documents/fltk/fltk-git] % ./configure --enable-x11 --enable-pango
checking build system type... x86_64-apple-darwin20.3.0
checking host system type... x86_64-apple-darwin20.3.0
…

checking for XftDrawCreate in -lXft... yes

configure: * * *  '--enable-pango' : using system-defaults * * *

configure: * * *  LIBS     =  -lpangoxft-1.0 -lpangoft2-1.0 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo -lXft -lfontconfig -lXinerama -pthread -lpthread  -lX11   * * *
configure: * * *  CXXFLAGS = -I/opt/sw/include -I/opt/sw/include/freetype2 -I/opt/X11/include  -mmacosx-version-min=10.9 -D_LIBCPP_HAS_THREAD_API_PTHREAD  -I/usr/X11/include  * * *
checking pango/pango.h usability... no
checking pango/pango.h presence... no
checking for pango/pango.h... no
checking pango/pangoxft.h usability... no
checking pango/pangoxft.h presence... no
checking for pango/pangoxft.h... no
checking for X11/extensions/Xdbe.h... yes
…

Configuration Summary
-------------------------------------------------------------------------
       Graphics: X11 + Xft + Xinerama

Here is the output of pango-related pkg-config commands on the same system :

[biomp2:~/Documents/fltk/fltk-git] % pkg-config --libs pangoxft pangocairo
-L/opt/sw/lib -L/opt/X11/lib -lpangoxft-1.0 -lpangoft2-1.0 -lfreetype -lfontconfig -lXft -lpangox-1.0 -lX11 -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lcairo

[biomp2:~/Documents/fltk/fltk-git] % pkg-config --cflags pangoxft pangocairo
-I/opt/sw/include/pango-1.0 -I/opt/sw/include -I/opt/sw/include/pango-1.0 -I/opt/sw/include/glib-2.0 -I/opt/sw/lib/glib-2.0/include -I/opt/sw/include/cairo -I/opt/sw/include -I/opt/sw/include/freetype2 -I/opt/X11/include

Then I went back to the unpatched configure.ac and obtained :

[biomp2:~/Documents/fltk/fltk-git] % ./configure --enable-x11 --enable-pango

…

checking for X11/Xft/Xft.h... yes
checking for XftDrawCreate in -lXft... yes

checking pango/pango.h usability... yes
checking pango/pango.h presence... yes
checking for pango/pango.h... yes
checking for pango_layout_new in -lpango-1.0... yes
checking for pango_xft_render_layout in -lpangoxft-1.0... yes
checking pango/pangoxft.h usability... yes
checking pango/pangoxft.h presence... yes
checking for pango/pangoxft.h... yes
checking for pango_layout_new in -lpango-1.0... (cached) yes
checking for pango_xft_render_layout in -lpangoxft-1.0... (cached) yes

checking for X11/extensions/Xdbe.h... yes

…

Configuration Summary
-------------------------------------------------------------------------
       Graphics: X11 + Xft + Xdbe + Xfixes + Xinerama + Xcursor + Xrender + Pango

[Albrecht Schlosser]

On 2/16/21 9:08 PM Manolo wrote:
> Albrecht: Here is the result of my test of patch pango.diff. It doesn't
> work :=(

Yep, that's what I expected (with the patch as-is). See below why.

> I tested on macOS to try something different than another Debian-based
> Linux.
>
> rm configure
> [biomp2:~/Documents/fltk/fltk-git] % patch -p1<pango.diff
> patching file configure.ac
> [biomp2:~/Documents/fltk/fltk-git] % autoconf -f
> [biomp2:~/Documents/fltk/fltk-git] % ./configure --enable-x11 --enable-pango

That's good so far

> configure: * * *  '--enable-pango' : using system-defaults * * *

This shows that it uses the "fallback" (using system-defaults).

> configure: * * *  LIBS     =  -lpangoxft-1.0 -lpangoft2-1.0
> -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo
> -lXft -lfontconfig -lXinerama -pthread -lpthread  -lX11   * * *

The LIBS variable (above) and CXXFLAGS (below) ...

> configure: * * *  CXXFLAGS = -I/opt/sw/include
> -I/opt/sw/include/freetype2 -I/opt/X11/include
> -mmacosx-version-min=10.9 -D_LIBCPP_HAS_THREAD_API_PTHREAD
> -I/usr/X11/include  * * *

are taken from the hardcoded values in configure.ac determined by the
host type:

AC_MSG_NOTICE([* * * '--enable-pango' : using system-defaults * * *])
AS_CASE([$host_os], [darwin*], [
dnl make sure LDFLAGS is appropriate for cairo (and Pango)
LDFLAGS="$($PKGCONFIG --libs cairo) $LDFLAGS"
], [linux*], [
CXXFLAGS="-I/usr/include/pango-1.0 -I/usr/include/fribidi
-I/usr/include/harfbuzz -I/usr/include/cairo $CXXFLAGS"
CXXFLAGS="-I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
$CXXFLAGS"
], [freebsd*], [
CXXFLAGS="-I/usr/local/include/pango-1.0
-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include $CXXFLAGS"
], [netbsd*], [
CXXFLAGS="-I/usr/pkg/include/pango-1.0 -I/usr/pkg/include/glib-2.0
-I/usr/pkg/lib/glib-2.0/include $CXXFLAGS"
CXXFLAGS="-I/usr/pkg/include/glib/glib-2.0 $CXXFLAGS"
PANGOLIBDIR="-L/usr/pkg/lib"
LDFLAGS="-Wl,-rpath,/usr/pkg/lib $LDFLAGS"
])
LIBS="$PANGOLIBDIR -lpangoxft-1.0 -lpangoft2-1.0 -lpangocairo-1.0
-lpango-1.0 -lgobject-2.0 -lglib-2.0 -lharfbuzz -lcairo $LIBS"

It appears that your build triggers case %host_os = darwin* which would
not set CXXFLAGS (!) and use pkg-config for "--libs cairo".

That's what I predicted to fail because the hardcoded values of flags
and libs can't work.

> Here is the output of pango-related pkg-config commands on the same system :
>
> [biomp2:~/Documents/fltk/fltk-git] % pkg-config --libs pangoxft pangocairo
> -L/opt/sw/lib -L/opt/X11/lib -lpangoxft-1.0 -lpangoft2-1.0 -lfreetype
> -lfontconfig -lXft -lpangox-1.0 -lX11 -lpangocairo-1.0 -lpango-1.0
> -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lcairo
>
> [biomp2:~/Documents/fltk/fltk-git] % pkg-config --cflags pangoxft pangocairo
> -I/opt/sw/include/pango-1.0 -I/opt/sw/include
> -I/opt/sw/include/pango-1.0 -I/opt/sw/include/glib-2.0
> -I/opt/sw/lib/glib-2.0/include -I/opt/sw/include/cairo -I/opt/sw/include
> -I/opt/sw/include/freetype2 -I/opt/X11/include

Thanks for this info.

That said, I wrote in my previous message:

"""
Line 1095/96:

# AS_IF([test x$PKGCONFIG != x], [
AS_IF([test x$PKGCONFIG = xxx], [

The first (original) line is commented out, the second line *disables*
the path where pkg-config is used. You can re-enable the first part by
just moving the '#' to the other line.
"""

So, after we saw that the fallback with hardcoded flags and libs does
NOT work, can you please edit these two lines above, moving '# ' down
one line so the first line is enabled and pkg-config will be used. This
ought to work. Hopefully. Can you please verify?

To be clear: this would be the "normal" patch. The one you tested was
modified to demonstrate the "fallback" code which I assumed would not
work (and did not work for my Linux build before I modified the flags
and libs so they returned the same as pkg-config). Sorry for the confusion.

A note to autoconf syntax, as far as I know (only the basics):

The main principle is that strings are quoted with [string], not
"string" or 'string'.

Many macros use syntax like:

AS_IF([condition], [then ...], [else...])

or similar

AS_CASE([$host_os], [darwin*], [code for darwin],
[linux*], [code for linux],
[freebsd*], [...]
[...])

These macros can be nested like this:

AC_CHECK_HEADERS([pango/pango.h pango/pangoxft.h], [
AC_CHECK_LIB([pango-1.0], [pango_layout_new], [
AC_CHECK_LIB([pangoxft-1.0], [pango_xft_render_layout], [
AC_DEFINE([USE_PANGO])
pango_found=yes
])
])
])

The effect is that the instruction part

AC_DEFINE([USE_PANGO])
pango_found=yes

is executed only if all conditions in the lines before are true.

[Manolo]

Albrecht: with this at line #1095 of configure.ac

        AS_IF([test x$PKGCONFIG != x], [

build with pango support runs well on macOS.

Many thanks also for these hints about the autoconf syntax.

[Albrecht Schlosser]

On 2/17/21 7:56 AM Manolo wrote:
> Albrecht: with this at line #1095 of configure.ac
>         AS_IF([test x$PKGCONFIG != x], [
> build with pango support runs well on macOS.

Thanks for confirmation.

I think we should drop that "fallback" code because it can never be
reliable. We should require pkg-config for pango as we do already for
freetype/fontconfig and maybe Xft (not sure which ones).

As Mike wrote (off-list) I agree that FLTK 1.4 would be a good time to
add this dependency for the build system.

Besides that users can also add hints to find libs with LDFLAGS and
CXXFLAGS env vars.

> Many thanks also for these hints about the autoconf syntax.

Welcome.

[Manolo]

On Wednesday, February 17, 2021 at 8:40:52 AM UTC+1 Albrecht Schlosser wrote:

I think we should drop that "fallback" code because it can never be
reliable. We should require pkg-config for pango as we do already for
freetype/fontconfig and maybe Xft (not sure which ones).

I agree too.

[Albrecht Schlosser]

Can you please test commit ba0b8affe33b ?

This should work always if pkg-config is available *and* pkg-config
finds the necessary Pango packages (and Xft as a prerequisite).

The old fallback is removed but there's the option to use CXXFLAGS and
LDFLAGS environment variables. However to test this you'd have to modify
configure.ac because xft requires pkg-config too.

In the future we might improve that again.

[Manolo]

On Wednesday, February 17, 2021 at 5:24:02 PM UTC+1 Albrecht Schlosser wrote:

Can you please test commit ba0b8affe33b ?

This should work always if pkg-config is available *and* pkg-config
finds the necessary Pango packages (and Xft as a prerequisite).

It works very well both under macOS and Ubuntu.
Many thanks.

[Ian MacArthur]

On 17 Feb 2021, at 07:40, Albrecht Schlosser wrote:
>
> I think we should drop that "fallback" code because it can never be reliable. We should require pkg-config for pango as we do already for freetype/fontconfig and maybe Xft (not sure which ones).

Do we depend on pkg-config for detecting XFT and fontconfig?
I don't think I knew that; we didn’t use too (in 1.3 I mean) and I’m not sure it seems like a good idea - not all Linux boxes have pkg-config, and we used to be pretty solid at finding XFT when it was installed... it (XFT) doesn’t have the complicated dependencies that pango has, really, so I can see the advantage of pkg-config for pango, but...?

[Manolo]

On Wednesday, February 17, 2021 at 8:30:59 PM UTC+1 imacarthur wrote:

Do we depend on pkg-config for detecting XFT and fontconfig?
I don't think I knew that; we didn’t use too (in 1.3 I mean) and I’m not sure it seems like a good idea - not all Linux boxes have pkg-config, and we used to be pretty solid at finding XFT when it was installed... it (XFT) doesn’t have the complicated dependencies that pango has, really, so I can see the advantage of pkg-config for pango, but...?

In FLTK 1.3.4, configure does this to detect XFT:

pkg-config --cflags xft

and, if not successful:

pkg-config --cflags freetype2

and, if not successful:

freetype-config --cflags

If none of that works, configure outputs:

please install pkg-config or use 'configure --disable-xft'.

and aborts.

[Manolo]

On Wednesday, February 17, 2021 at 9:18:07 PM UTC+1 Manolo wrote:

In FLTK 1.3.4, configure does this to detect XFT:

Typo above. I meant FLTK 1.3.5 really.

[Albrecht Schlosser]

On 2/17/21 9:18 PM Manolo wrote:
>
> On Wednesday, February 17, 2021 at 8:30:59 PM UTC+1 imacarthur wrote:
>
> Do we depend on pkg-config for detecting XFT and fontconfig?
> I don't think I knew that; we didn’t use too (in 1.3 I mean) and I’m
> not sure it seems like a good idea - not all Linux boxes have
> pkg-config, and we used to be pretty solid at finding XFT when it
> was installed... it (XFT) doesn’t have the complicated dependencies
> that pango has, really, so I can see the advantage of pkg-config for
> pango, but...?
>
> In FLTK 1.3.4, configure does this to detect XFT:

(corrected by Manolo later to 1.3.5)

> pkg-config --cflags xft
> and, if not successful:
> pkg-config --cflags freetype2
> and, if not successful:
> freetype-config --cflags
>
> If none of that works, configure outputs:
> please install pkg-config or use 'configure --disable-xft'.
> and aborts.

It was not our deliberate choice to do that. In earlier versions we used
freetype-config, but freetype-config has been removed on newer systems
such that you have to use pkg-config (or none of them).

Today I modified configure.ac for detecting pango in a way that we first
try pkg-config to determine which flags and libs we need and if this
does not succeed we go ahead and try to find the libs anyway.

The reason to do this was something Mike Sweet wrote in an off-list
conversation: you can always use CFLAGS/CXXFLAGS/LDFLAGS environment
variables if pkg-config is not available.

And indeed, I used in my tests something like this:

export CFLAGS="`pkg-config --cflags pangocairo pangoxft`"
export CXXFLAGS="`pkg-config --cflags pangocairo pangoxft`"
export LDFLAGS="`pkg-config --libs pangocairo pangoxft`"
./configure --enable-pango

For my test I disabled the detection of pango flags and libs with
pkg-config (which would do something to the same effect internally) and
this really built the FLTK libs and test programs with pango. Note: I
had to edit configure.ac for this test because otherwise it would have
aborted earlier in the xft detection.

This means: this strategy *would* work if someone didn't have pkg-config
*and* set the correct CFLAGS/CXXFLAGS/LDFLAGS for their system. Whether
this is useful I can't tell, but it *does* work.

We could do something similar for the detection of xft/freetype, i.e.
not abort the configure job but continue anyway if pkg-config is not
available. Again, the user would have to provide the correct flags in
CFLAGS/CXXFLAGS/LDFLAGS instead.

That said, configure would still abort if it didn't *find* the libs, but
you wouldn't have to install pkg-config if you can set the
CFLAGS/CXXFLAGS/LDFLAGS properly for your system.

Does this make sense for the reader? I hope I explained this strategy
clearly enough. If not, please feel free to ask...

BTW: we're also using pkg-config for the detection of Cairo libs. We
could take a similar approach for this as well.

[Lauri Kasanen]

On Wed, 17 Feb 2021 19:30:56 +0000
Ian MacArthur wrote:

> On 17 Feb 2021, at 07:40, Albrecht Schlosser wrote:
> >
> > I think we should drop that "fallback" code because it can never be reliable. We should require pkg-config for pango as we do already for freetype/fontconfig and maybe Xft (not sure which ones).
>
> Do we depend on pkg-config for detecting XFT and fontconfig?
> I don't think I knew that; we didn’t use too (in 1.3 I mean) and I’m not sure it seems like a good idea - not all Linux boxes have pkg-config, and we used to be pretty solid at finding XFT when it was installed...

(been a while since my last list post)

IMHO pkg-config is a totally acceptable dep. Unlike e.g. cmake which is
massive, pita, and a massive pita, pkg-config is small, standard, and
the default macros let you override the flags. If you happen to build
on a very old Linux box and don't want to override the flags manually,
installing pkg-config is not a big deal (unlike cmake, again).

- Lauri

[Manolo]

On Wednesday, February 17, 2021 at 10:18:45 PM UTC+1 Albrecht Schlosser wrote:

This means: this strategy *would* work if someone didn't have pkg-config
*and* set the correct CFLAGS/CXXFLAGS/LDFLAGS for their system. Whether
this is useful I can't tell, but it *does* work.

We could do something similar for the detection of xft/freetype, i.e.
not abort the configure job but continue anyway if pkg-config is not
available. Again, the user would have to provide the correct flags in
CFLAGS/CXXFLAGS/LDFLAGS instead.

That said, configure would still abort if it didn't *find* the libs, but
you wouldn't have to install pkg-config if you can set the
CFLAGS/CXXFLAGS/LDFLAGS properly for your system.

Alternative proposal:

configure still aborts in that case but gives a richer warning message:

Please install pkg-config, or set CXXFLAGS/LDFLAGS adequately for XFT, or use 'configure --disable-xft'.

BTW: we're also using pkg-config for the detection of Cairo libs. We
could take a similar approach for this as well.

Definitely yes.

[Albrecht Schlosser]

On 2/18/21 8:39 AM Manolo wrote:
>
> On Wednesday, February 17, 2021 at 10:18:45 PM UTC+1 Albrecht Schlosser
> wrote:
>
> This means: this strategy *would* work if someone didn't have
> pkg-config *and* set the correct CFLAGS/CXXFLAGS/LDFLAGS

> for their system. ...

>
> We could do something similar for the detection of xft/freetype, i.e.
> not abort the configure job but continue anyway if pkg-config is not
> available. Again, the user would have to provide the correct flags in
> CFLAGS/CXXFLAGS/LDFLAGS instead.
>
> That said, configure would still abort if it didn't *find* the libs,

> but you wouldn't have to install pkg-config ...

>
> Alternative proposal:
> configure still aborts in that case but gives a richer warning message:
> Please install pkg-config, or set CXXFLAGS/LDFLAGS adequately for XFT,
> or use 'configure --disable-xft'.

Yes, indeed, I wasn't sure about the best warning/error messages. This
could be improved and eventually unified for all these pkg-config vs.
*FLAGS cases.

> BTW: we're also using pkg-config for the detection of Cairo libs. We
> could take a similar approach for this as well.
>
> Definitely yes.

Yep, this is a long standing issue.

I'm putting this on my todo list but this can take a while, I'm too busy
with other stuff. However, if anybody else volunteers ... please drop a
note here.