December 1998 - XEmacs-Beta - XEmacs Mailing List Archives

[Success] XEmacs 21.0-b59 "Poitou59", i386-pc-win32 26 years, 4 months

Adrian Aichner

This works under WindowsNT natively compiled: nmake -f xemacs.mak GUNG_HO=1 ... As a previous report states, USE_UNION_TYPE=1 fails to compile src\glyphs-msw.c(1736) Adrian > XEmacs Build Report as generated > by build-report-version $Revision: 1.53 $ follows: > Contents of d:\export\home\tmp\21.0\xemacs\nt\Installation: > (Output from most recent run of ./configure)

1 participants
0 comments

[Failure] XEmacs 21.0-b59 "Poitou59", i386-pc-win32 26 years, 4 months

Adrian Aichner

Build fails in src\glyphs-msw.c when compiling with nmake -f xemacs.mak USE_UNION_TYPE=1 GUNG_HO=1 ... The offending bits are these: XSETINT (IMAGE_INSTANCE_PIXMAP_HOTSPOT_X (ii), find_keyword_in_vector (instantiator, Q_hotspot_x)); XSETINT (IMAGE_INSTANCE_PIXMAP_HOTSPOT_Y (ii), find_keyword_in_vector (instantiator, Q_hotspot_y)); Adrian Next try will be nmake -f xemacs.mak USE_UNION_TYPE=1 ... > XEmacs Build Report as generated > by build-report-version $Revision: 1.53 $ follows: > Contents of d:\export\home\tmp\21.0\xemacs\nt\Installation: > (Output from most recent run of ./configure)

2 participants
1 comments

Re: make check failure 26 years, 4 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: ... > BTW, I got so many files this time ;-), that I get some `permission denied' > errors too on the following dirs: > - etc/gnusrefcard/Attic/ > - lisp/gnus/Attic/ > - lisp/utils/Attic > What's this Attic stuff ? Stuff that was in 20.2 that has been moved. It isn't relevant to XEmacs 21, it's only needed if one wishes to recreate an XEmacs 20.2 or previous.

1 participants
0 comments

[Failure] XEmacs 21.0-b59 "Poitou59", i386-pc-win32 26 years, 4 months

Adrian Aichner

Fails to build as nmake -f xemacs.mak USE_UNION_TYPE=1 ... Adrian > XEmacs Build Report as generated > by build-report-version $Revision: 1.53 $ follows: > Contents of d:\export\home\tmp\21.0\xemacs\nt\Installation: > (Output from most recent run of ./configure)

1 participants
0 comments

Re: set-standard-case-table broken? 26 years, 4 months

Christoph Wedler

>>>>>"CN" == Christian Nybø <s911254(a)stud.nhh.no> writes: CN> I upcase the string "Dø, e e i a æ å". I get "Dø, E E I A æ å". CN> Then I do: CN> (set-case-table iso8859/1-case-table) CN> and the above string upcases to "DØ, E E I A Æ Å". Good. Now, I'd CN> like this behaviour for all buffers, and do CN> (set-standard-case-table iso8859/1-case-table) CN> , create a new buffer, and try with the same string. CN> Contrary to the docs, it does not upcase the chars above address 128. Unfortunatly, this is a (reported) bug since ages (19.13?). IMHO, there should be a section "known bugs" somewhere in the XEmacs docs. - Christoph

1 participants
0 comments

Re: make check failure 26 years, 4 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: ... > I've updated with `cvs update -Pd', but I don't seem to get the same > stuff as what appears on cvs.xemacs.org. One more thought. What version of cvs are you using? As nearly as I can tell, cvs-1.10* is poison. At least I haven't seen it pass all its self-checks on any platform I've tried it on. The version being used on cvs.xemacs.org is 1.9.18 and it exhibits lots of strange, unexpected and wonderful behavior and that might be part of the problem. Your best bet (IMO) is vanilla cvs-1.9 if that version will work on your system. I've put a copy of vanilla CVS 1.9 in the aux directory on the FTP site: ftp://ftp.xemacs.org/pub/xemacs/aux/ or you can still get it from the main GNU site ftp://prep.ai.mit.edu/pub/gnu/ the last time I checked.

2 participants
1 comments

Re: make check failure 26 years, 4 months

Didier Verna

SL Baur writes: sb> One more thought. What version of cvs are you using? Concurrent Versions System (CVS) 1.10.2 (client/server) sb> As nearly as I can tell, cvs-1.10* is poison. At least I haven't seen it sb> pass all its self-checks on any platform I've tried it on. The version sb> being used on cvs.xemacs.org is 1.9.18 and it exhibits lots of strange, sb> unexpected and wonderful behavior and that might be part of the problem. sb> Your best bet (IMO) is vanilla cvs-1.9 if that version will work on your sb> system. sb> I've put a copy of vanilla CVS 1.9 in the aux directory on the FTP site: sb> ftp://ftp.xemacs.org/pub/xemacs/aux/ sb> or you can still get it from the main GNU site sb> ftp://prep.ai.mit.edu/pub/gnu/ sb> the last time I checked. Thanks. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: make check failure 26 years, 4 months

Didier Verna

SL Baur writes: sb> Try another cvs update at the top level and if that doesn't work, try an sb> explicit `cvs update test-harness.el' in tests/automated. However, if only sb> the latter works, something is broken and needs to be fixed. Got it. Pffffew. None of the updates worked, not even for a particular file (I didn't have the `automated' dir at all). I finally tried this, which is completely redundant: `cvs update -Pd -rrelease-21-2' and I think this time I got everything. There must really be something broken. BTW, I got so many files this time ;-), that I get some `permission denied' errors too on the following dirs: - etc/gnusrefcard/Attic/ - lisp/gnus/Attic/ - lisp/utils/Attic What's this Attic stuff ? -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: make check failure 26 years, 4 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > I suppose this is due to a cvs update problem: ... > | xemacs exiting.Cannot open load file: /infres/metheny/latest/XEmacs-21.2/src/../tests/automated/test-harness.el > | gmake[1]: *** [check] Error 255 > | gmake[1]: Leaving directory `/infres/metheny/latest/xemacs/src' > | gmake: *** [check] Error 2 > | zsh: exit 2 gmake check > `----- That file is present in CVS and I see it is being picked up in a `cvs checkout'. > I've updated with `cvs update -Pd', but I don't seem to get the same > stuff as what appears on cvs.xemacs.org. I know there's a problem with the XEmacs package file hack-package-index.el (I had to manually `cvs update hack-package-index.el' to have it picked up. Try another cvs update at the top level and if that doesn't work, try an explicit `cvs update test-harness.el' in tests/automated. However, if only the latter works, something is broken and needs to be fixed.

1 participants
0 comments

Re: sorry for the trouble.... 26 years, 4 months

SL Baur

Damon Lipparelli <lipp(a)primus.com> writes in xemacs-beta(a)xemacs.org: > But, what is the CVS branch tag for the 21.2 release? Use the tag `-rrelease-21-2' on `cvs checkout'. It will get the latest sources in the branch. The XEmacs Build 'bot uses the following to obtain fresh source from CVS:[1] #! /bin/zsh -f # Written by SL Baur <steve(a)xemacs.org> # December, 1998 # This file is part of XEmacs and is used by the maintainers # for creating distributions # CleanDist: Fetch a brand new distribution tree # Usage: CleanDist MAJOR MINOR setopt extendedglob set -e # Exit at the first sign of trouble if [ $# != 3 ]; then echo "Usage: $0: MAJOR MINOR RELOAD" exit 1 fi MAJOR=$1 MINOR=$2 RELOAD=$3 export BUILDDIR=xemacs-${MAJOR}.${MINOR} case ${MAJOR}.${MINOR} in 21.0) release= ;; 21.2) release=-rrelease-21-2 ;; esac # First remove the results of the previous build if they are still present if [ -d ${BUILDDIR} ]; then if [ -f ${BUILDDIR}/Makefile ]; then (cd ${BUILDDIR}; make distclean) fi [ "$RELOAD" = t ] && cvs -Q release -d ${BUILDDIR} fi # Second checkout what will become the next version [ "$RELOAD" = t ] && cvs checkout ${release} -d ${BUILDDIR} xemacs exit 0 Footnotes: [1] This script has a bug in it. If the RELOAD flag isn't set, it should do `cvs update' instead. It also makes the assumption that CVSROOT is properly set in the environment.

1 participants
0 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta December 1998