Hi Alex, Thanks for your feedback.
Alex Shinn <alexsh...@gmail.com> skribis: > On Sat, Feb 11, 2012 at 12:53 AM, Ludovic Courtès <l...@gnu.org> wrote: >> >>> * R7RS feature identifiers: r7rs, exact-closed, ratios, exact-complex, >>> ieee-float, full-unicode, windows, posix, unix, darwin, linux, bsd, >>> freebsd, solaris, i386, x86-64, ppc, sparc, jvm, clr, llvm, ilp32, >>> lp64, ilp64, big-endian, little-endian, guile, guile-2, guile-2.0 >> >> I wonder how these are specified. Does a *-kfreebsd-gnu build have >> ‘freebsd’? And ‘bsd’? Do *-gnu* have ‘linux’ defined, even when Linux >> isn’t used? Does Cygwin have ‘unix’? > > First note the list of feature identifiers is one of the > things most likely to be trimmed in the next draft. Good. :-) > There is no "gnu" feature proposed in R7RS, That would be for GNU, aka. GNU/Hurd. > The point about the "unix" feature being vague is well > taken. It’s not just ‘unix’, see the above examples. >> And above all: are people going to write #ifdef __linux__ish code when >> what they mean is #ifdef __GLIBC__ or even something different? > > This particular analogy doesn't apply. IMO it applies in the sense that, as with C code, people will check for ‘linux’ when what they really care about is what the libc provides, or whether the core utilities support --color, etc. The libc/kernel confusion has been causing a lot of troubles to people porting C applications from GNU/Linux to GNU/kFreeBSD and GNU/Hurd. This class of problem should be avoided as much as possible. [...] > Regardless, we're likely to add a disclaimer that you > should only resort to cond-expanded code as a last > resort. Yes, definitely. I haven’t checked whether R7RS has something like that, but I think it would be nice to provide well-defined, fine-grain indicators instead. For instance, a ‘file-separator’ variable, which would be ‘/’ on Unices and Cygwin, and ‘\’ on raw Windows. Thanks, Ludo’.
