tech-pkg archive

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

Re: Failure message when inconsistent X11_TYPE

Frederic Fauberteau <> 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 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

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

  xemacs is no longer maintained upstream (the current stable release
  has a distfile date of March 2015)

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index