Re: [Q21.5] Incremental Garbage Collector (revised)

SJT> Why doesn't this case XE_DIE? If there's a reason why developers SJT> would want this, there needs to be an option to enable it. We SJT> should _never_ allow an autodetected configuration that contains SJT> a crash we know how to prevent. Yes, you are right. I don't know too much about how to do the autoconf stuff correctly... I appreciate your review! What about this patch: Index: configure.ac =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/configure.ac,v retrieving revision 1.22 diff -u -r1.22 configure.ac --- configure.ac 25 Nov 2005 01:41:36 -0000 1.22 +++ configure.ac 25 Nov 2005 11:36:25 -0000 ＠＠ -1703,7 +1703,7 ＠＠ linux* ) check_vdb_posix=yes ;; freebsd ) check_vdb_posix=yes ;; dnl bail out immediately -dnl * ) have_vdb_fake=yes ;; +dnl * ) XE_DIE("No write barrier implementation available on this system.") dnl if not sure, try posix first, maybe we are lucky * ) check_vdb_posix=yes ;; esac ＠＠ -5963,15 +5963,6 ＠＠ fi if test "$have_vdb_mach" = yes ; then echo " Using mach exception mechanism as vdb fault handler." -fi -if test "$have_vdb_fake" = yes && test "$enable_vdb" != fake; then - echo " WARNING: ---------------------------------------------------------" - echo " WARNING: The new incremental garbage collector is enabled, but" - echo " WARNING: a virtual dirty bit implementation is not yet available" - echo " WARNING: on this system. XEmacs will crash if you try to switch on" - echo " WARNUNG: incremental garbage collection!" - echo " WARNING: Use \`--disable-newgc' to turn incremental gc off." - echo " WARNING: ---------------------------------------------------------" fi if test "$have_vdb_fake" = yes && test "$enable_vdb" == fake; then echo " Virtual dirty bit write barrier manually disabled." Note that the XE_DIE case is commented out: Currently I'd prefer to test if the platform supports POSIX if it is not listed explicitly. Later, when this list is more complete, the XE_DIE case should be used. If you do not want to have the comment in at all, I'll remove it. BTW, the option to force a write barrier is already there: `--with-vdb=TYPE'. SJT> However, I would like to ask about the extreme repetitiveness of the SJT> patch; is there no way to use macro magic to avoid all of those SJT> (some hunk) SJT> #ifdef NEW_GC SJT> /* a couple lines of code */ SJT> #else /* NEW_GC */ SJT> (next hunk) SJT> #endif /* NEW_GC */ SJT> ? Currently I cannot come up with anything nicer or less repetitive. Someone else? -- Marcus