How to implement partly-system-dependent mostly-portable code?

[Rem@IMSSS]

When writing code that will run on many systems, with most of the code
portable but a small part different on various systems, there comes
the problem of how to organise the various files that contain the
various parts of the code and how to link the portable code with the
system-dependent code. I'm wrestling with this currently in PSL, and
would be interested in hearing how Common LISP implementors did it, as
well as ideas from others. My ideas are below ("existing code" refers to
my IMSSS softare that is presently being ported to CMS and will soon
also be ported to other machines).

 (1) The way my existing code does it, namely have all versions in the
      source an all versions compiled, but at runtime a global
      variable chooses each time which piece of code to execute
     [advanges: simple;
      disadvantages: confuses FCHECK; requires global variable at
        runtime; takes a lot more memory at runtime; takes some more
        time to execute each time; compilation takes much longer since
        it has to compile everything for every machine every time]
 (2) The same except using macros to select which body of code to compile
     [advantages: minimum runtime memory; minimum runtime CPU time;
      disadvantages: still requires versions of source for all systems 
        around when compiling for any system, thus taking longer to
        read it in and slightly longer to select correct version to
        compile; requires the macro to know what the target machine
        will be, something I'm not sure the cross-compiler maks
        available to user macros]
 (3) Keep system-dependent stuff in separate files, using funny names
      such as SYSDEP-foo as the way the system-dependent stuff is
      called from the portable files, keep user-callable function in
      portable source files with link to SYSDEP-foo function, and with
      comments indicating where the SYSDEP-foo function might be found
     [advantages: minimum runtime memory; minimum runtime CPU time;
      disadvantages: (a) if functions used as linkage, slightly more
      CPU time (b) if macros used as linkage, you won't be able to
      TRace system functions by their usual name at runtime unless the
      TRace package is smart enough to map (TRace OPEN) into (TRace
      SYSDEP-OPEN) for example.]
 (4) Same except have user call the system-dependent functions
      directly, i.e. they have advertised names rather than funny
      names via vector from advertised names
     [advantages: minimum runtime memory; minimum runtime CPU time;
      disadvantages: confusing to maintainers since they have no idea
        whether a function is in portable files or in some random
        system dependent file]
-------