10:23 a.m.
Hi,
I've just cvs up'ed my whole package tree, and I can't compile semantic
anymore. I get a stack trace ending with:
Loading /usr/local/src/XEmacs-Packages/xemacs-packages/ede/auto-autoloads... # bind (
stack-trace-on-signal debug-on-signal stack-trace-on-error debug-on-error)
signal(error ("Given parent class eieio-persistent is not a class"))
# bind (data error-symbol)
signal-error(error ("Given parent class eieio-persistent is not a class"))
# bind (error-data)
normal-top-level()
# (condition-case ... . error)
# (catch top-level ...)
Given parent class eieio-persistent is not a class
xemacs exiting
On the other hand, both ede and eieio compiled fine.
Any ideas ?
--
European Lisp Symposium, May 2009: http://www.european-lisp-symposium.org
European Lisp Workshop, July 2009: http://elw.bknr.net/2009
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:57 p.m.
Didier Verna writes:
I've just cvs up'ed my whole package tree, and I can't
compile semantic
anymore.
Trying nuking the tree, start from scratch. Even "make
ridiculously-clean" is failing to get rid of all state, it seems.
(IIRC you need to do the scorched-earth thing with of all of eieio,
ede, and semantic, at least.) You also need a fairly recent 21.5
(definitely post 21.5.28) or at least 21.4.22.
semantic and friends give a whole new meaning to the term "killer
app".
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:18 p.m.
Hi,
Stephen J. Turnbull writes:
> Trying nuking the tree, start from scratch. Even "make
> ridiculously-clean" is failing to get rid of all state, it seems.
The smoketest does a "make distclean" between runs and that seems to be
enough.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:39 p.m.
Mats Lidell writes:
Stephen J. Turnbull writes:
>> Trying nuking the tree, start from scratch. Even "make
>> ridiculously-clean" is failing to get rid of all state, it seems.
The smoketest does a "make distclean" between runs and that seems to be
enough.
OK, but I've found that sometimes distclean isn't enough, and somebody
else recently reported that distclean wasn't enough. Then, if you
once get a build that succeeds, it becomes impossible to replicate the
bug.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:04 p.m.
>>>> Stephen wrote:
Stephen> OK, but I've found that sometimes distclean isn't enough, and
Stephen> somebody else recently reported that distclean wasn't enough.
Stephen> Then, if you once get a build that succeeds, it becomes
Stephen> impossible to replicate the bug.
So you are suggesting that the smoketest should try harder to start
from a clean state in order to find more problems?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:16 a.m.
Mats Lidell writes:
>>>>> Stephen wrote:
Stephen> OK, but I've found that sometimes distclean isn't enough, and
Stephen> somebody else recently reported that distclean wasn't enough.
Stephen> Then, if you once get a build that succeeds, it becomes
Stephen> impossible to replicate the bug.
So you are suggesting that the smoketest should try harder to start
from a clean state in order to find more problems?
I don't know what this implies for the smoke test. I would argue that
the smoke test probably should start from a clean slate to find
*fewer* problems. A problem that goes away by building in a fresh
checkout probably is not something that should hold up the smoketest,
since the workaround is easy but fixing the problem may not be.
Rather, we want the smoketest to find problems that prevent a build
even in a fresh checkout, and get them fixed as fast as possible.
Also, the smoketest is a peculiar beast that rebuilds on almost every
checkin. So it's likely to have a different state from everybody
else, but only you have access to that state. So if it catches this
kind of hard-to-reproduce bug, debugging it will be a burden on you,
personally. If you think that's a good use of your time, I don't
mind. ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:03 p.m.
>>>> Stephen wrote:
Stephen> Rather, we want the smoketest to find problems that prevent a
Stephen> build even in a fresh checkout, and get them fixed as fast as
Stephen> possible.
Yes that is the idea. I got the impression that distclean might not
take the package tree into the same state as a fresh checkout although
my experience seems to indicate that it really does.
Stephen> So if it catches this kind of hard-to-reproduce bug,
Stephen> debugging it will be a burden on you, personally. If you
Stephen> think that's a good use of your time, I don't mind. ;-)
Well, it doesn't have a peculiar state because it starts from a
distcleaned state every time (And that seems to be, from my
experience, really close to a fresh checkout.) So when the smoketest
finds a problem, all the rest of you need only distclean before
building to reproduce!
Anyway, I'll stay with just performing distclean between the builds
for now until there is more evidence that we need to clean even more.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:45 p.m.
On Tue, Mar 3, 2009 at 4:03 PM, Mats Lidell <matsl(a)xemacs.org> wrote:
Yes that is the idea. I got the impression that distclean might not
take the package tree into the same state as a fresh checkout although
my experience seems to indicate that it really does.
There have been a few occasions when I've had to do a "make extraclean".
Each time, it was because some generated file was not marked as generated in
the Makefile. Then, on upgrading the containing package, the file would not
get regenerated from the new sources. Each time I have discovered something
like that, I've bugged the maintainer to fix the Makefile. Maybe there are
no cases like this left. To be sure, somebody needs to:
(1) build all of the packages in a fresh CVS checkout;
(2) do a "make distclean" there; and
(3) diff against another fresh CVS checkout.
--
Jerry "Somebody" James
http://loganjerry.googlepages.com/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:16 p.m.
Stephen J. Turnbull wrote:
Trying nuking the tree, start from scratch. Even "make
ridiculously-clean" is failing to get rid of all state, it seems.
(IIRC you need to do the scorched-earth thing with of all of eieio,
ede, and semantic, at least.) You also need a fairly recent 21.5
(definitely post 21.5.28) or at least 21.4.22.
OK, it seems that I needed a "make distclean && make elcclean" first,
and then XEmacs 21.4.22 (I had 21 only).
Thanks.
--
European Lisp Symposium, May 2009: http://www.european-lisp-symposium.org
European Lisp Workshop, July 2009: http://elw.bknr.net/2009
Scientific site: http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5530
days inactive
5532
days old
8 comments
4 participants
participants (4)
-
Didier Verna -
Jerry James -
Stephen J. Turnbull -
The XEmacs Package Smoketest