> > Okay, here's the updated scheme.
> >
> > *) There is a platform/generic.c and platform/generic.h. (OK, it'll
> > probably really be unixy, but these days it's close enough) If there is
no
> > pltform-specific file, this is the one that gets copied to platform.c
and
> > platform.h
> >
> > *) If there *is* a platform specific file it may, and probably should
> > unless it plans on overriding everything, include generic.c and
generic.h.
> >
> > *) All entries in generic.c should be bracketed with "#if
> > !defined(OVERRIDE_funcname)" and any functions that the platform defines
> > that override one in generic.c should have a corresponding #define
> > OVERRIDE_function in the platform-specific .h file
> >
> > Yeah, this is definitely a pain. If someone's got a better idea I'm all
ears...
>
> Sounds like less of a pain and more forward-looking than maintaining
> dozens of nearly-identical unixy platform files.
>
> Looks like a good plan to me. Portability's a pain no matter how you
> slice it. It's just a hard problem. I don't think there's an easy
> solution.
I like this idea too. I think we need one generic.[ch] file for all
platforms.
The unix.[ch], win32.[ch], macos.[ch] will cover most of our needs. Each
platform can define its own porting file.
Instead of defining zillions of OVERRIDE_funcname, I like to use plain name,
such as
// platform.h
INLINE ll_eq(int64_t a, int64_t b) {
return memcmp(&a, &b, sizeof(a)) == 0;
}
#define ll_eq ll_eq
// generic.h
#ifndef ll_eq
#define ll_eq(a, b) ((a) == (b)) // assuming compiler support 64-bit int
#endif
The porting interface includes constants and functions. We should assume
the functions may be implemented as macros. So & is prohibited on porting
interface. (This is mainly for speed reason.) Portable structures are
very unlikely, such as "struct sockaddr_in" and "struct timeval". Parrot
may need to define its own structs.
Hong
