Frederic Fauberteau <triaxx%NetBSD.org@localhost> writes: > Hauke Fath wrote: >> On Tue, 20 Jul 2021 15:16:38 -0400, Greg Troxel wrote: >>> I think your point is that the check blowing up on mkfontdir should only >>> happen if the package has USE_TOOLS+= mkfontdir, and that code that does >>> not try to use X11 should not complain. >> >> Precisely. > > You mentioned PKG_DEFAULT_OPTIONS being set to -x11 but > editors/xemacs-packages doesn't implement the options framework. > > $ make show-var VARNAME=USE_TOOLS > printf pax find gawk gzip gtar perl:run [ awk dirname echo grep pwd > sed test true date tr awk:pkgsrc cut:pkgsrc echo:pkgsrc pwd:pkgsrc > sed:pkgsrc tr:pkgsrc uname:pkgsrc awk cat cmp diff echo find grep rm > sed test touch true ftp:bootstrap digest:bootstrap gtar gzcat patch > digest:bootstrap [ awk basename cat chgrp chmod chown cmp cp cut > dirname echo egrep env false fgrep find grep head hostname id install > ln ls mkdir mv printf pwd rm rmdir sed sh sort tail test touch tr true > wc xargs expr mkfontdir:run > > mkfontdir has been added by FONTS_DIRS.x11 as reminded by Joerg. When > I look at the PLIST file, I understand that this tool generates fonts > in the 3 directories listed in FONTS_DIRS.x11. Then it is needed to > build the package and must be provided by either a xbase set or by > pkgsrc. > > I'm not an emacs user and I don't know the architecture of package > tree for this editor. But I don't understand why you try to build > editors/xemacs-packages on a sans-X11 machine while there is > editors/emacs-packages. Maybe we could move FONTS_DIRS.x11 of > editors/xemacs-packages from Makefile to options.mk but I'm not sure > if it is relevant since I can read that XEmacs is an editor for X > Window systems. So, it seems clear that the xemacs-packages actually does depend on x11, and the new code has correctly flagged a situation where X11_TYPE is native but the tools are missing, which I expect leads to a situation where the binary package is different than in the standard approach. It would be interesting to look at the build log and see what happens when mkfontdir is attempted to be invoked. Really that failure should fail the build. One could also build xemacs-packages on a system with X11_TYPE=modular but no installed packages and see what gets pulled in. So far, pkgsrc doesn't have X11_TYPE=none. I suppose that would mean that any attempt to depend on X11 (tools or libs) would throw an error. That's currently semi-handled by setting modular and not building things that use X. We also don't have any notion of QT5_TYPE=none or GTK_TYPE=none to fail building. So I'd say that if you don't install the X11 sets in NetBSD, you should set X11_TYPE to modular, and if you haven't done that your system is misconfigured. I use emacsNN-nox11 which avoids an X11 dependency. (While my system has X, I consider emacs to be critical and prefer a leaner build.) There is, amusingly enough even though it is sensible, xemacs-nox11. So xemacs-packages should perhaps grow an x11 option and omit the fonts entirely if it is turned on, or be split into xemacs-packages and xemacs-packages-x11. As an aside not logically related to the x11 issues, the xemacs DESCRs don't say: xemacs is a fork of GNU emacs they imply that a lot of GNU emacs features touted are special xemacs features xemacs is no longer maintained upstream (the current stable release has a distfile date of March 2015)
Attachment:
signature.asc
Description: PGP signature