Mercurial > hg > xemacs-beta
view nt/config.inc.samp @ 938:0391335b65dc
[xemacs-hg @ 2002-07-31 07:14:49 by michaels]
2002-07-17 Marcus Crestani <crestani@informatik.uni-tuebingen.de>
Markus Kaltenbach <makalten@informatik.uni-tuebingen.de>
Mike Sperber <mike@xemacs.org>
configure flag to turn these changes on: --use-kkcc
First we added a dumpable flag to lrecord_implementation. It shows,
if the object is dumpable and should be processed by the dumper.
* lrecord.h (struct lrecord_implementation): added dumpable flag
(MAKE_LRECORD_IMPLEMENTATION): fitted the different makro definitions
to the new lrecord_implementation and their calls.
Then we changed mark_object, that it no longer needs a mark method for
those types that have pdump descritions.
* alloc.c:
(mark_object): If the object has a description, the new mark algorithm
is called, and the object is marked according to its description.
Otherwise it uses the mark method like before.
These procedures mark objects according to their descriptions. They
are modeled on the corresponding pdumper procedures.
(mark_with_description):
(get_indirect_count):
(structure_size):
(mark_struct_contents):
These procedures still call mark_object, this is needed while there are
Lisp_Objects without descriptions left.
We added pdump descriptions for many Lisp_Objects:
* extents.c: extent_auxiliary_description
* database.c: database_description
* gui.c: gui_item_description
* scrollbar.c: scrollbar_instance_description
* toolbar.c: toolbar_button_description
* event-stream.c: command_builder_description
* mule-charset.c: charset_description
* device-msw.c: devmode_description
* dialog-msw.c: mswindows_dialog_id_description
* eldap.c: ldap_description
* postgresql.c: pgconn_description
pgresult_description
* tooltalk.c: tooltalk_message_description
tooltalk_pattern_description
* ui-gtk.c: emacs_ffi_description
emacs_gtk_object_description
* events.c:
* events.h:
* event-stream.c:
* event-Xt.c:
* event-gtk.c:
* event-tty.c:
To write a pdump description for Lisp_Event, we converted every struct
in the union event to a Lisp_Object. So we created nine new
Lisp_Objects: Lisp_Key_Data, Lisp_Button_Data, Lisp_Motion_Data,
Lisp_Process_Data, Lisp_Timeout_Data, Lisp_Eval_Data,
Lisp_Misc_User_Data, Lisp_Magic_Data, Lisp_Magic_Eval_Data.
We also wrote makro selectors and mutators for the fields of the new
designed Lisp_Event and added everywhere these new abstractions.
We implemented XD_UNION support in (mark_with_description), so
we can describe exspecially console/device specific data with XD_UNION.
To describe with XD_UNION, we added a field to these objects, which
holds the variant type of the object. This field is initialized in
the appendant constructor. The variant is an integer, it has also to
be described in an description, if XD_UNION is used.
XD_UNION is used in following descriptions:
* console.c: console_description
(get_console_variant): returns the variant
(create_console): added variant initialization
* console.h (console_variant): the different console types
* console-impl.h (struct console): added enum console_variant contype
* device.c: device_description
(Fmake_device): added variant initialization
* device-impl.h (struct device): added enum console_variant devtype
* objects.c: image_instance_description
font_instance_description
(Fmake_color_instance): added variant initialization
(Fmake_font_instance): added variant initialization
* objects-impl.h (struct Lisp_Color_Instance): added color_instance_type
* objects-impl.h (struct Lisp_Font_Instance): added font_instance_type
* process.c: process_description
(make_process_internal): added variant initialization
* process.h (process_variant): the different process types
author | michaels |
---|---|
date | Wed, 31 Jul 2002 07:14:49 +0000 |
parents | 79c6ff3eef26 |
children | 5f2f8dcbfb3e |
line wrap: on
line source
# -*- mode: makefile -*- ############################################################################ INSTALL_DIR=c:\Program Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING) PACKAGE_PREFIX=c:\Program Files\XEmacs ############################################################################ # Multilingual support. MULE=0 # Native MS Windows support. HAVE_MS_WINDOWS=1 # X Windows support. Not working at all and probably never will. If you # want X support under MS Windows, compile with Cygwin instead. HAVE_X_WINDOWS=0 X11_DIR= # GTK support. Do NOT set this to 1; as of xemacs-21.5-b6 # gtk-xemacs is not supported on MSWindows (mingw or msvc). # Yes, we know that gtk has been ported to native MSWindows # but XEmacs is not yet ready to use that port. HAVE_GTK=0 GTK_DIR= ############################################################################ # Set this to enable XPM support (virtually mandatory), and specify # the directory containing xpm. HAVE_XPM=1 XPM_DIR=c:\src\xpm-3.4k # Set this to enable GIF support. HAVE_GIF=1 # Set this to enable PNG support (virtually mandatory), and specify # the directories containing png and zlib. HAVE_PNG=1 PNG_DIR=c:\src\libpng-1.0.9 ZLIB_DIR=c:\src\zlib # Set this to enable TIFF support, and specify the directory containing tiff. HAVE_TIFF=0 TIFF_DIR= # Set this to enable JPEG support, and specify the directory containing jpeg. HAVE_JPEG=1 JPEG_DIR=c:\src\jpeg-6b # Set this to enable XFace support, and specify the directory containing # compface. HAVE_XFACE=0 COMPFACE_DIR= ############################################################################ # Set this to specify the location of makeinfo. (If not set, XEmacs will # attempt to use its built-in texinfo support when building info files.) MAKEINFO=c:\src\texinfo-4.0\makeinfo\makeinfo.exe ############################################################################ # Set this to turn on optimization when compiling. OPTIMIZED_BUILD=0 # Set this to build with the fastcall calling convention, which uses registers # instead of the stack and should speed things up a bit # #### Change to 1 when I check in the ws with support for fastcall USE_FASTCALL=0 # Set this to compile in support for profiling. If you want line-by-line # profiling under VC++, you also need debugging turned on. PROFILE_SUPPORT=0 ############################################################################ # Development options # ############################################################################ # Set this to enable debug code in XEmacs that doesn't slow things down, # and to add debugging information to the executable. (The code that's # enabled in XEmacs is primarily extra commands that aid in debugging # problems. The kind of debugging code that slows things down -- # i.e. internal error-checking -- is controlled by the ERROR_CHECK_ALL # variable, below.) DEBUG_XEMACS=1 # True if running VC++ 6 or later. HAVE_VC6=1 # Uncomment this to turn off or on the error-checking code, which adds # abundant internal error checking (and slows things down a lot). Normally, # leave this alone -- it will be on for beta builds and off for release # builds. # ERROR_CHECK_ALL=0 # Set this to speed up building, for development purposes. QUICK_BUILD=0 # Set this to see exactly which compilation commands are being run (not # generally recommended). VERBOSECC=0 # Set this to get nmake to use dependency info (recommended for development). # Requires cygwin or ActiveState versions of Perl to be installed. DEPEND=0 # Set this to use the portable dumper for dumping the preloaded Lisp # routines, instead of the older "unexec" routines in unexnt.c. USE_PORTABLE_DUMPER=1 # Set this to get improved type checking of Lisp_Objects -- with this # setting, they're declared as unions instead of ints, and so places where # a Lisp_Object is mistakenly passed to a routine expecting an int (or # vice-versa), or a check is written `if (foo)' instead of `if (!NILP # (foo))', will be flagged as errors. (All of these do NOT lead to the # expected results! Qnil is not represented as 0 (so if (foo) will # *ALWAYS* be true for a Lisp_Object), the representation of an integer as # a Lisp_Object is not just the integer's numeric value (but usually 2x the # integer +/- 1). # Some also claim it simplifies debugging, but I don't really believe them. # Definitely don't do your normal builds this way, because you may well get # less efficiency, and could conceivably trigger compiler bugs (has definitely happened, many times, with gcc). # USE_UNION_TYPE=1