* On 2022-12-14 at 10:29 GMT, Sean Champ wrote:
>~~~~~
>.if ${X11_TYPE} != "modular" && \
> !exists(${X11BASE}/${PKGCONFIG_DIR}/sm.pc) && \
> !exists(${X11BASE}/lib${LIBABISUFFIX}/pkgconfig/sm.pc)
>.include "../../mk/x11.buildlink3.mk"
>.else
>[...]
>~~~~~
I think a better long-term solution for this would be to use
mk/buildlink3/find-pkgconfig-files.mk and extend BUILTIN_PKGCONFIG_DIRS
for the X11BASE != modular case.
That way you don't need to hardcode paths in each buildlink3.mk file,
and can just use BUILTIN_FIND_PKGCONFIG_FILES for each .pc.
Definitely. For what it's worth, I'd discovered this variable in pkgsrc mk-files, a little while after sending the email.,
So, this seems that it should work out under site mk.conf for the pkgconfig integration on the FreeBSD machine, without needing any patching:
BUILTIN_PKGCONFIG_DIRS= /usr/local}/libdata/pkgconfig
I haven't verified this yet, albeit. As an expedient hack, I'd actually set LIBABISUFFIX=data for the pkgtools/x11-links build only, so that the build could find the pkg-config files from the FreeBSD ports build. That seemed to work out, such that it could then emulate the corresponding pkg libs and pkg includes from the original pkg files, using symlinks to host files, I think.
Albeit departing from my hack of an idea yesterday and the original topic of the first email, but further along in the USE_BUILTIN approach, I wasn't able to get the gettext and libiconv integration to work out for USE_BUILTIN.libiconv=yes and USE_BUILTIN.gettext=yes. For any pkg build that would depend on libiconv or gettext, of course if the builtin alternative is not working out, then any of the pkg builds depending on those could not be used as builtin.
Returning to the USE_BUILTIN approach, I wonder if it could be possible to make a port that would function in some ways similar to pkgtools/x11-links but for the host libiconv and host gettext libs? If the build would have everything it needs from the host libraries and host includes for gettext and libiconv support, then maybe it could work out under USE_BUILTIN in the buildlink support.
Ideally, this might be able to extend so far as to use any of the opengl support built on the host?
Perhaps the hypothetical i18n-links/l10n-links port could reuse something like BUILDLINK_FILES_CMD.iconv and BUILDLINK_FILES_CMD.gettext but for creating the list of symbolic links for emulating pkg iconv and pkg gettext under the USE_BUILTIN case? For producing the list of links needed for each, perhaps it might be as simple as querying the host pkg system - ideally, then filtering for libs and includes. With the resulting links then installed under the destdir for pkg build, maybe the build would be able to find libintl.h then, and the libiconv and gettext libs from the host.
Departing further from my original email albeit: When testing out a USE_BUILTIN approach with the python310 build, I'd ran into an issue about the bdb version I was trying to use in the build. For Python 3.10, it needed db >= 3.3, <= 5.3, while I'd set BDB_DEFAULT=db6 under mk.conf. Subsequently, I've developed a patch for making the dbm module optional in Python 3.10, in addition to adding [BDB_ACCEPTED=db3 db4 db5] when the option is enabled. I guess the patch for the additional build option could be sent to the pkgsrc-bugs list? I haven't taken a look at the Python 3.11 or Python < 3.10 builds as yet, maybe they could support a similar option. For the python310 case, I'll try to test the build again with the dbm option enabled, before sending any patch.
Departing entirely from the initial topic albeit, but if one may introduce an idea of an ends in a usage case, looking at wip/py-dask - maybe it could be used for building something functionally like FreeBSD's poudriere and in the spirit of pkgbuild, though assembled with Python? Futures and scheduling, I think I can grok these ideas. Albeit, I believe Dask might be more oriented towards data center applications, but perhaps it could serve in an approach for build automation too.
Thx for hearing me out on the hack of an idea.