tech-pkg archive

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

building with native X11 type on FreeBSD - pkgconfig dir and pkgtools/x11-links



Hello, all,

After taking a look at some of the latest developments with packaging for Python projects, as subsequent of PEP 517 and related items, I've begun working on a pkgsrc installation on FreeBSD 13.1. I already have something of an existing mk.conf configuration on hand, which I've tested to some extent, using pkgsrc builds on FreeBSD and Debian systems. I may be able to test this out on openSUSE, shortly.

I'm testing out the builds for my pkgsrc configuration on FreeBSD by building wip/emacs-git for an Xaw toolkit with X11_TYPE=native and XAW_TYPE=neXtaw. I've defined my X11_BASE=/usr/local/include for the pkgsrc builds on FreeBSD.

In the process of this, I've discovered that a number of the buildlink3.mk files under x11 are using a pathname such as ${X11BASE}/lib/pkgconfig/sm.pc for locating a package's pc file. I understand that this pathname might be where sm.pc would be available on most hosts.

With pkgsrc on FreeBSD under this configuration, sm.pc would be available at ${X11BASE}/libdata/pkgconfig/sm.pc.

With sm.pc not found - though it's available on the host - this may affect the pkgtools/x11-links build and any builds that would use the x11-links pkg together with X11_TYPE=native. With a small patch, though. sm.pc is found ... and then I can debug the next instance, lol

To try to make this pathname more portable, I've begun testing out a patch where I've defined a variable PKGCONFIG_DIR?=lib/pkgconfig in mk/buildlink3/pkgconfig-builtin.mk I'm then patching each buildlink3.mk such as to use the following, for example in x11/libSM/buildlink3.mk
~~~~
.if ${X11_TYPE} != "modular" && \
    !exists(${X11BASE}/${PKGCONFIG_DIR}/sm.pc) && \
    !exists(${X11BASE}/lib${LIBABISUFFIX}/pkgconfig/sm.pc)
.include "../../mk/x11.buildlink3.mk"
.else
[...]
~~~~

I can then set PKGCONFIG_DIR=libdata/pkgconfig in my mk.conf, such that the pkgsrc build can find the existing sm.pc file on the host.

After patching each x11 pkg-port for this, then rebuilding and reinstalling pkgtools/x11-links it seems to be working out. Perhaps a similar patch could be applied for each buildlink3.mk in each pkg that would provide a library referenced under the pkgtools/x11-links files dir. I'm certain that there may be other ports using a simlar pkgconfig dir, outside of those using X11_TYPE in the build. I suppose I'm just focusing on the X11_TYPE ports for now.

Before developing a complete patch for this approach, I though it might be helpful to communicate with the list here. I'm not certain what the consensus could be about defining a PKGCONFIG_DIR as such, or defining it in mk/buildlink3/pkgconfig-builtin.mk.

This configuration seems to work out here, for using libraries from the host's pkg/ports system under local builds.

To facilitate the USE_BUILTIN definitions, I'm also using the following in mk.conf
~~~~
USE_HOST_LIBS+= bzip2 zlib png freetype2 libXmu libXext libXt libX11 libXaw3d
USE_HOST_LIBS+= libXau libXdmcp libXext libX11  libXpm  libXt xorgproto
USE_HOST_LIBS+= libXft libSM libICE

.for P in ${USE_HOST_LIBS}
USE_BUILTIN.${P}= yes
PREFER.${P}= native
PREFER_NATIVE+= ${P}
CHECK_BUILTIN.${P}= no
.endfor
~~~~

It seems to be working out,  so far.

I've avoided setting LIBABISUFFIX=data here. It seems that might have a similar affect in e.g  x11/libSM/buildlink3.mk and it would not need a patch on the pkgsrc tree, but I'm not sure if it's the right approach - assuming LIBABISUFFIX must have some other purpose.

Could one ask, Thoughts about this patch idea?

Health, all,

- Sean



Home | Main Index | Thread Index | Old Index