pkgsrc-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: pkgsrc/x11/fltk13



Am Wed, 26 May 2021 10:44:54 +0200
schrieb Michael Bäuerle <micha%NetBSD.org@localhost>: 

> This change should be reverted:
> The libXcursor dependency is now listed twice

Damn. Another case of a patch bitrotting for too long and me not seeing
that it is outdated despite still applying without issue.

Thanks for spotting that.

>, libxcb is not a direct
> dependency of FLTK (see below) and the bl3 file is out of sync (again).

I verified that it indeed shows up in .buildlink without the explicit
mention. Back when I created the patch, it was not the case and I had
build troubles with mixing-in of host libs.

About the bl3: Yes. I forgot that. I have to wonder why even attempts
to share dependencies between Makefile and bl3 are undesired. I once
had a long-ish depends.mk which was included in both but was asked to
remove that and instead manually duplicate the entries.

Is it a Zen-like practice to require developers to remember to change
duplicate code in multiple places? Seems odd to me.

Anyhow:
 
> Proposed lines to add for the ${OPSYS} != "Darwin" sections:
> | 
> | .include "../../fonts/fontconfig/buildlink3.mk"
> | .include "../../x11/libX11/buildlink3.mk"
> | .include "../../x11/libXrender/buildlink3.mk"

OK … looking what fltk configure links directly …

conf.log:checking for X11/extensions/Xfixes.h... yes
conf.log:checking for XFixesQueryExtension in -lXfixes... yes
conf.log:       Graphics: X11 + Xft + Xdbe + Xfixes + Xinerama + Xcursor + Xrender

ltk-config:LDLIBS="-lXrender -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm  -lX11 "

We then cover Xrender, Xcursor, Xext, Xft, fontconfig, Xinerama, X11 …
missing Xfixes. I see -lXfixes in libXcursor.la, libxcb-xfixes.la. But
since it is mentioned explicitly in the build, should we add that, too?

Also:

checking for xprop... /usr/bin/xprop

I wonder if that is needed in the build. Should it be a tool
dependency? Maybe its path is built into some binary or config?

Looking into configure.ac:

       AC_CACHE_CHECK(for X overlay visuals, ac_cv_have_overlay,
            if test "x$XPROP" != x; then
                if $XPROP -root 2>/dev/null | grep -c "SERVER_OVERLAY_VISUALS" >/dev/null; then
                    ac_cv_have_overlay=yes
                else
                    ac_cv_have_overlay=no
                fi
            else
                ac_cv_have_overlay=no
            fi)

        if test x$ac_cv_have_overlay = xyes; then
            AC_DEFINE(HAVE_OVERLAY)
        fi

It's checking a property of the currently running server(?). That's ugly.

What do we do with that? I'd expect the build to be reproducible
independently of being called in an X11 terminal or plain console (or
no interactive terminal at all).


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg



Home | Main Index | Thread Index | Old Index