Compiling No Gnus for XEmacs

Compiling No Gnus for XEmacs

[Robert Pluim]

Hi,

I've got the latest No Gnus from git, and done

./configure && make EMACS=xemacs

which results in:

cd lisp && make EMACS="xemacs" lispdir="/usr/local/share/xemacs/site-packages/lisp/gnus" all
make[1]: Entering directory `/cygdrive/c/Documents and Settings/RPluim/.xemacs/gnus/lisp'
rm -f *.elc gnus-load.el auto-autoloads.* custom-load.*
URLDIR="/cygdrive/c/Documents and Settings/RPluim/.xemacs/xemacs-packages/lisp/w3/" W3DIR="/cygdrive/c/Documents and Settings/RPluim/.xemacs/xemacs-packages/lisp/w3/" lispdir="/usr/local/share/xemacs/site-packages/lisp/gnus" srcdir=. xemacs -batch -no-autoloads -l ./dgnushack.el -f dgnushack-make-cus-load .

Loading cus-dep...

xemacs exiting.
Cannot open load file: "advice"make[1]: *** [gnus-load.el] Error 255
make[1]: Leaving directory `/cygdrive/c/Documents and Settings/RPluim/.xemacs/gnus/lisp'
make: *** [lick] Error 2


I'm using 

"XEmacs 21.5  (beta29) \"garbanzo\" 4f98237e23fc [Lucid] (i686-pc-cygwin, Mule) of Thu May 20 2010 on RPluim"

The obvious but probably wrong solution is:

--- lisp/Makefile	2010-09-07 19:05:48.828924100 +0200
+++ lisp/Makefile~	2010-09-07 19:04:36.609711900 +0200
@@ -7,7 +7,7 @@
 top_srcdir = ..
 
 EMACS = xemacs
-FLAGS = -batch -l $(srcdir)/dgnushack.el
+FLAGS = -batch -no-autoloads -l $(srcdir)/dgnushack.el
 INSTALL = /usr/bin/install -c
 INSTALL_DATA = ${INSTALL} -m 644
 SHELL = /bin/sh


Suggestions welcome.

Robert

-- 

Re: Compiling No Gnus for XEmacs

[Lars Magne Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I've got the latest No Gnus from git, and done
>
> ./configure && make EMACS=xemacs
>
> which results in:

[...]

> Cannot open load file: "advice"make[1]: *** [gnus-load.el] Error 255
> make[1]: Leaving directory `/cygdrive/c/Documents and Settings/RPluim/.xemacs/gnus/lisp'

I'm unable to reproduce that.  It seems to work for me...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Compiling No Gnus for XEmacs

[Robert Pluim]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I've got the latest No Gnus from git, and done
>>
>> ./configure && make EMACS=xemacs
>>
>> which results in:
>
> [...]
>
>> Cannot open load file: "advice"make[1]: *** [gnus-load.el] Error 255
>> make[1]: Leaving directory `/cygdrive/c/Documents and Settings/RPluim/.xemacs/gnus/lisp'
>
> I'm unable to reproduce that.  It seems to work for me...
>

On further investigation, I now see why this happens. I bet you have
your packages installed in /usr/local/share/xemacs, right? I have mine
under ~/.xemacs, putting them in /usr/local solves it. I guess this
means a trip to xemacs-beta.

Thanks

Robert

Re: Compiling No Gnus for XEmacs

[Katsumi Yamaoka]

Oops, I posted it to another thread.  Beat me please!

Robert Pluim wrote:
[...]
> Loading cus-dep...

> xemacs exiting.
> Cannot open load file: "advice"make[1]: *** [gnus-load.el] Error 255
> make[1]: Leaving directory `/cygdrive/c/Documents and Settings/RPluim/.xemacs/gnus/lisp'
> make: *** [lick] Error 2

I've introduced defadvice to directory-files in order to exclude
the lisp/.dir-locals.el file.  So, I may be the culprit, though
I have no such problem in building the latest Gnus with XEmacs.
I'll look into it further...

Re: Compiling No Gnus for XEmacs

[Katsumi Yamaoka]

Robert Pluim wrote:
> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
[...]
>> I'm unable to reproduce that.  It seems to work for me...

> On further investigation, I now see why this happens. I bet you have
> your packages installed in /usr/local/share/xemacs, right? I have mine
> under ~/.xemacs, putting them in /usr/local solves it.

But why does it do the trick?
Because of the -no-autoloads option, XEmacs doesn't know the module
from which to get `defadvice'.  For it dgnushack.el provides the
autoload:

    (unless (fboundp 'defadvice)
      (autoload 'defadvice "advice" nil nil 'macro))

Even with that if XEmacs fails in loading advice.elc, it will mean
there's no such module in the `load-path' directories.  I got
(in Windows Vista):

$ xemacs -batch -no-autoloads -eval '(message "%s" (locate-library "advice"))'
/usr/share/xemacs/xemacs-packages/lisp/xemacs-base/advice.elc

I can hardly imagine why the behavior changes by changing the
installation directory.

Re: Compiling No Gnus for XEmacs

[Robert Pluim]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Robert Pluim wrote:
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> [...]
>>> I'm unable to reproduce that.  It seems to work for me...
>
>> On further investigation, I now see why this happens. I bet you have
>> your packages installed in /usr/local/share/xemacs, right? I have mine
>> under ~/.xemacs, putting them in /usr/local solves it.
>
> But why does it do the trick?
> Because of the -no-autoloads option, XEmacs doesn't know the module
> from which to get `defadvice'.  For it dgnushack.el provides the
> autoload:
>
>     (unless (fboundp 'defadvice)
>       (autoload 'defadvice "advice" nil nil 'macro))
>
> Even with that if XEmacs fails in loading advice.elc, it will mean
> there's no such module in the `load-path' directories.  I got
> (in Windows Vista):
>
> $ xemacs -batch -no-autoloads -eval '(message "%s" (locate-library "advice"))'
> /usr/share/xemacs/xemacs-packages/lisp/xemacs-base/advice.elc
>
> I can hardly imagine why the behavior changes by changing the
> installation directory.

It's because of the way XEmacs has early- and non-early package
paths. ~/.xemacs is where the early packages are searched for, and
-no-autoloads suppresses looking there, but does not suppress looking in
the other package paths, hence moving the files to /usr/local/ makes
things work again.

Robert

Re: Compiling No Gnus for XEmacs

[Katsumi Yamaoka]

Robert Pluim wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
[...]
>> But why does it do the trick?
[...]
> It's because of the way XEmacs has early- and non-early package
> paths. ~/.xemacs is where the early packages are searched for, and
> -no-autoloads suppresses looking there, but does not suppress looking in
> the other package paths, hence moving the files to /usr/local/ makes
> things work again.

I see.  Thanks for tracking it down.