At 08:59 AM 9/13/2001 -0400, Andy Dougherty wrote:
>On Wed, 12 Sep 2001, Dan Sugalski wrote:
>
> > > > changing parrot.h to do #include "parrot/config.h" and
> > > > then changing
> > > > Makefile to add -I./include to CCFLAGS.
>
> > One thing to keep in mind is that the directory may not be sufficient on
> > some platforms. VMS, specifically, ignores the directory portion of the
> > include filename. (And the suffix, generally, but that's separate)
>
>Hmm. So would you suggest adding -I[.include] -I[.include.parrot] for VMS
>as well? (My VMS days were a very long time ago.)
It's not the compiler switches. That's just a portability issue. The issue
is making sure we can safely differentiate between, say, our strings.h and
the system one. Prepending a directory isn't necessarily enough to make
sure that happens. I'm not sure that
#include "parrot/strings.h"
is any safer than
#include "strings.h"
and I know less-recent versions of Dec C did what I'd consider
counter-intuitive (from a Unix perspective, at least) things with path
prefixes on headers. It's usually just a problem with system headers, but I
remember being bit with user headers. (Our system headers aren't actual
separate files--they're just entries in one big text library)
> > Not, mind, that I'm proposing prepending parrot_ to all the filenames,
> > though that's an option certainly.
>
>That would be fun on 8.3 filesystems :-).
I'm seriously considering not going out of our way to support what could be
reasonably considered antique systems. That'd include DOS-only machines. I
don't think we should actively discourage them, but neither do I think we
should be bound by their limitations.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
