1:26 a.m.
No Luck with NEW_GC on native Windows yet, using
wget http://www.crestani.de/xemacs/newgc.patch
Patch applied flawlssly with
patch --forward --verbose --strip=1 < newgc.patch
Best regards,
Adrian
XEmacs Build Report generated by emacs-version
21.5 (beta23) "daikon" (+CVS-20051031) XEmacs Lucid
with system-configuration
i586-pc-win32
follows:
Contents of
c:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.5-clean\Installation:
(Output from most recent run of ./configure)
OS version:
Microsoft Windows XP [Version 5.1.2600]
OS: Windows_NT
XEmacs 21.5-b23 "daikon" (+CVS-20051101) configured for `i586-pc-win32'.
Building XEmacs using "NMAKE".
Building XEmacs using make flags " ".
Building XEmacs in source tree
"c:\\Hacking\\cvs.xemacs.org\\XEmacs\\xemacs-21.5-clean".
For src, using compiler "cl -nologo -W3 -DSTRICT -Zi -Od -MDd -c -TP
-Ic:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.5-clean\nt\inc
-Ic:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.5-clean\src
-I"c:\Hacking\libs4xemacs\xpm-3.4k"
-I"c:\Hacking\libs4xemacs\xpm-3.4k\lib"
-I"c:\Hacking\libs4xemacs\libpng-1.0.2"
-I"c:\Hacking\libs4xemacs\zlib"
-I"c:\Hacking\libs4xemacs\tiff-v3.4\libtiff"
-I"c:\Hacking\libs4xemacs\jpeg-6b" -I"c:\Hacking\libs4xemacs\compface"
-I"c:\Hacking\libs4xemacs\zlib" -DHAVE_MS_WINDOWS -DHAVE_MENUBARS
-DHAVE_SCROLLBARS -DHAVE_TOOLBARS -DHAVE_WIDGETS -DHAVE_DIALOGS -DHAVE_XPM -DFOR_MSW
-DHAVE_GIF -DHAVE_PNG -DHAVE_TIFF -DHAVE_JPEG -DHAVE_XFACE -DHAVE_ZLIB -DHAVE_NATIVE_SOUND
-DMULE -DPDUMP -DNEW_GC -DUSE_KKCC -DMC_ALLOC -DSYSTEM_MALLOC -DDEBUG_XEMACS -D_DEBUG
-DWIN32_LEAN_AND_MEAN -DWIN32_NATIVE -Demacs -DHAVE_CONFIG_H
-DPATH_VERSION=\"21.5-b23\" -DPATH_PROGNAME=\"xemacs\"
-DEMACS_VERSION=\"21.5-b23\" -DEMACS_PROGNAME=\"xemacs\"
-DSTACK_TRACE_EYE_CATCHER=xemacs_21_5_b23_i586_pc_win32 -DPATH_PREFIX=\"..\"
-DEMACS_MAJOR_VERSION=21 -DEMACS_MINOR_VERSION=5 -DEMACS_BETA_VERSION=23
-DXEMACS_CODENAME=\""daikon"\"
-DXEMACS_EXTRA_NAME=\"(+CVS-20051101)\"
-DEMACS_CONFIGURATION=\"i586-pc-win32\"
-DPATH_PACKAGEPATH=\""~\\.xemacs;;c:\\Program
Files\\XEmacs\\site-packages;c:\\Program Files\\XEmacs\\mule-packages;c:\\Program
Files\\XEmacs\\xemacs-packages"\"".
For lib-src, using compiler "cl -nologo -W3 -DSTRICT -Zi -Od -MDd
-Ic:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.5-clean\lib-src
-Ic:\Hacking\cvs.xemacs.org\XEmacs\xemacs-21.5-clean\src -DHAVE_CONFIG_H
-DWIN32_NATIVE".
Compiling as C++.
Installing XEmacs in "c:\\Program Files\\XEmacs\\XEmacs-21.5-b23".
Package path is "~\\.xemacs;;c:\\Program Files\\XEmacs\\site-packages;c:\\Program
Files\\XEmacs\\mule-packages;c:\\Program Files\\XEmacs\\xemacs-packages".
Compiling in support for Microsoft Windows native GUI.
Compiling in international (MULE) support.
Compiling in support for XPM images.
Compiling in support for GIF images.
Compiling in support for PNG images.
Compiling in support for TIFF images.
Compiling in support for JPEG images.
Compiling in support for X-Face message headers.
Compiling in support for GZIP compression/decompression.
Compiling in support for toolbars.
Compiling in support for dialogs.
Compiling in support for widgets.
Compiling in support for native sounds.
Using portable dumper.
Using system malloc.
Using DLL version of C runtime library.
Compiling in debugging support (no slowdown).
Using new experimental GC algorithms.
Using new experimental allocator.
Using new experimental incremental garbage collector.
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3:34 p.m.
>>>>"APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> No Luck with NEW_GC on native Windows yet,
using
APA> wget http://www.crestani.de/xemacs/newgc.patch
The incremental garbage collector crashes on Windows when the build
process tries to build the core lisp .elc files. The same is the case
on Solaris, as Malcolm reported. I was able to reproduce the crashes
and am working on them now.
Enable the new garbage collector in a workspace that already has the
.elc files should work, though.
Is there a reason why "make clean" does not delete the core lisp .elc
files? I missed this in my test runs...
--
Marcus
7:25 p.m.
Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
>>>>>"APA" == Adrian Aichner
<adrian(a)xemacs.org> writes:
APA> No Luck with NEW_GC on native Windows yet, using
APA> wget http://www.crestani.de/xemacs/newgc.patch
The incremental garbage collector crashes on Windows when the build
process tries to build the core lisp .elc files. The same is the case
on Solaris, as Malcolm reported. I was able to reproduce the crashes
and am working on them now.
Enable the new garbage collector in a workspace that already has the
.elc files should work, though.
Is there a reason why "make clean" does not delete the core lisp .elc
files? I missed this in my test runs...
I always use
make distclean
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
8:06 p.m.
>>>> "Adrian" == Adrian Aichner
<adrian(a)xemacs.org> writes:
Adrian> Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
> Is there a reason why "make clean" does not delete the
core lisp .elc
> files? I missed this in my test runs...
Adrian> I always use make distclean
This doesn't remove lisp/*.elc either. In fact no Makefile target does.
I think that the justification is that
a) the files are portable
b) change very rarely
c) take a very long time to regenerate
so they might as well be kept around.
I agree that it's surprising behaviour. Should their removal be added to the
'realclean' target?
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
8:12 p.m.
Malcolm Purvis <malcolmp(a)xemacs.org> writes:
>>>>> "Adrian" == Adrian Aichner
<adrian(a)xemacs.org> writes:
Adrian> Marcus Crestani <crestani(a)informatik.uni-tuebingen.de> writes:
>> Is there a reason why "make clean" does not delete the core lisp .elc
>> files? I missed this in my test runs...
Adrian> I always use make distclean
This doesn't remove lisp/*.elc either. In fact no Makefile target does.
Sure does for a native Windows build with nt\xemacs.mak, which has this:
distclean: nicenclean configclean
-$(DEL) $(BLDLIB_SRC)\$(CONFIG_VALUES)
-$(DEL) $(INFODIR)\*.info*
-$(DEL) $(LISP)\*.elc
-$(DEL) $(LISP)\mule\*.elc
-$(DEL) $(LISP)\term\*.elc
I think that the justification is that
a) the files are portable
b) change very rarely
c) take a very long time to regenerate
so they might as well be kept around.
I agree that it's surprising behaviour. Should their removal be added to the
'realclean' target?
Malcolm
--
Adrian Aichner
mailto:adrian＠xemacs.org
http://www.xemacs.org/
3 a.m.
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
Malcolm> This doesn't remove lisp/*.elc either. In fact no
Malcolm> Makefile target does.
Unfortunate.
Malcolm> I think that the justification is that
Malcolm> a) the files are portable
Malcolm> b) change very rarely
Malcolm> c) take a very long time to regenerate
d) there is no lisp/Makefile.
e) are part of the distribution and GNU standards say not to delete
them in "user" targets.
Malcolm> I agree that it's surprising behaviour. Should their
Malcolm> removal be added to the 'realclean' target?
According to the toplevel Makefile:
## when they don't work right. (beta can't depend on distclean, which
## removes necessary files generated by configure.)
and realclean depends on distclean. I think the `beta' target
probably should depend on the clean target that removes .elcs. So I
would guess we should have either a separate elcclean target that only
cleans generated lisp (it should also nuke the generated .els, I
think), or the elcclean target could depend on clean. I lean to the latter.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
4:03 a.m.
Marcus Crestani wrote:
Is there a reason why "make clean" does not delete the core
lisp .elc
files? I missed this in my test runs...
This is done because, traditionally at least, it was very time consuming
to rebuild the .elc files (esp. when the whole world was in core). We
should probably consider changing at least one of the "greater cleans";
e.g. `make realclean' should surely remove the .elc files, since its
definition is "Delete everything from the current directory that can be
reconstructed with this Makefile." i'll change this unless someone objects.
ben
5:44 p.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> We should probably consider changing at least one of the
Ben> "greater cleans"; e.g. `make realclean' should surely remove
Ben> the .elc files, since its definition is "Delete everything
Ben> from the current directory that can be reconstructed with
Ben> this Makefile." i'll change this unless someone objects.
Please make "make beta" depend on this. According to the makefile,
make beta can't depend on realclean, though.
--
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6954
days inactive
6956
days old
8 comments
5 participants
participants (5)
-
Adrian Aichner -
Ben Wing -
Malcolm Purvis -
Marcus Crestani -
Stephen J. Turnbull