Hi,
an interesting problem has been plaguing the pkgsrc editors/xemacs build
for a while.
Some time ago, I updated editors/xemacs-packages to deploy the
pre-release packages from beta/experimental/packages. Since that update,
rebuilding xemacs with editors/xemacs{,-packages} installed will fail with
[...]
Loading loadhist.el...
Loading loaddefs.el...
Loading site-load.el...
Bootstrapping from temacs...
Compiling /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.el...
>Error occurred processing
/usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.el: Opening output
file: directory not writable or nonexistent,
/usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.elc
Done
+ exit 1
*** [update-elc.stamp] Error code 1
make[1]: stopped in /var/obj/pkgsrc/editors/xemacs/work/xemacs-21.4.24/src
1 error
[...]
That is, there is no compiled equivalent for hebrew.el
% > ls -l /usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.*
-rw-r--r-- 1 root wheel 24602 Dec 14 2015
/usr/pkg/lib/xemacs/xemacs-packages/lisp/leim/hebrew.el
%
and the xemacs build feels called to compile the installed el file,
which as an unprivileged build it cannot.
Now, is it a problem when packages ship some of their source files
uncompiled?
And if it isn't, why should the xemacs build system attempt to recompile
arbitrary installed el files?
And where exactly in the build does that happen?
Would the strategy be to make sure that all packages install compiled
sources, or to slap the wrist of xemacsens build system when it tries to
reach out beyond the build directory?
Cheerio,
hauke
--
The ASCII Ribbon Campaign Hauke Fath
() No HTML/RTF in email Institut für Nachrichtentechnik
/\ No Word docs in email TU Darmstadt
Respect for open standards Ruf +49-6151-16-21344