making clisp build more robust

[Bruno H. <br...@cl...>]

Hi,

The first thing many people see from clisp are build failures.

Two months ago, I tried to list the causes of these build failures:
  1. GC-safety bugs
  2. address range layout and MAP_FIXED
  3. C compiler miscompiles something (e.g. Solaris cc)
  4. Assembler, can be turned off by -DNO_ASM (= -DSAFETY=3) - but ari80386.d
     still makes trouble (e.g. Solaris x86 with cc)
  5. Use of rarely used C interfaces, like <asm/page.h> and such.
  6. #if-ology that are not tested by Makefile.devel's multibuild.

Here's what has been done about them and can be done in the future.

1. We have a reliable way to detect GC-safety bugs:
   build with CC=g++ and --debug-gcsafety, then run "make check".
   But this relies of good test coverage in the test suite.

   New GC-safety bugs occasionally crop in again. That's life. But it is
   helpful if continuous integration builds would catch and signal them soon.

2.+4. I added an option --enable-portability that, among other things,
   - Enables the most conservative memory model (-DNO_ADDRESS_SPACE_ASSUMPTIONS).
     On 32-bit platforms this is the WIDE_SOFT model, on 64-bit platforms it is
     ONE_FREE_BIT_HEAPCODES with SPVW_PAGES (and thus no generational GC).
   - Disables generational GC,
   - Disables all use of ari*.d assembly language files (-DNO_ARI_ASM).

3. Solaris cc is unusable, both on SPARC and x86/x86_64. Any better idea than
   to document in unix/PLATFORMS to avoid it?

5. In general, gnulib is the way to go, in order to avoid the maintenance
   effort of using rarely used C interfaces. I think we're using it well,
   nothing more to do here.

6. There are now 'multibuild-*' targets in Makefile.devel. But it's only in
   combination with continuous integration that they provide their full
   benefits.

Bruno