Re: [MINTOS] compiler switch (was: Re: MiNT goes UNiX, ...)

[dsb@cs.duke.edu (Scott Bigham)]

>The only information the __MINT__ switch provides, is that the target
>operating system is MiNT rather than pure Gemdos.

Not even that much, in fact; all it says is that the code is being
compiled with the MiNTlibs.  The libs do a lot of backward-bending to
handle TOS environments.

>                                                  What we need is a switch
>that tells a bit more about the target system in general: for example that
>reasonable filesystems (like minixfs) will be used (no need to mess around
>with filenames like bison.simple or .profile), and that the environment
>variables should follow the Unix conventions (PATH, MANPATH, etc.).

But that's not the point.  I'm trying to write code that runs on a
GEMDOS filesystem but takes advantage of MinixFS if it's present; that
runs under TOS but takes advantage of MiNT if it's present; and so on.
I don't want to limit the utility of the programs I write to just us
UNIX freaks ;) , and I don't want to have to build a different version
of my programs for every kind of target system someone might want to
run them on..  That means runtime checks of the local system's setup,
and I think __MINT__ is still the most appropriate #ifdef to wrap those
checks in.

>There shouldn't be any compiler dependent code in an application, that's
>what the P1003.1 types (size_t, ssize_t, clock_t, ...) are all about.

Heh.  Were it only so simple.  Many's the time I've had to add some
#ifdef __HSC__'d lines to kludge around features that HSC simply didn't
support (really large arrays, for instance).

						-sbigham