> Some of the NetBSD ports predefine unix=1 and some, at least alpha, do not.

Actaully, as far as I can tell, in the EGCS (src/gnu/dist) compiler
tree, several ports are also in the condition where they don't define
it (at least ARM and mips).


> I've been told that "the project" decided two years ago to drop this
> predefine, but then did not do it. Although it would be acceptable to me
> to have it or not have it, at a minimum our various ports must do the same
> thing. Anyway two years is a long time, and I think the older discussion
> has exceeded its TTL, especially since no action was taken.

Actually, longer than two years.  And the notion was to wait a release
or two after it was announced, _then_ do it, is _some_ lag time was to
be expected.


> And obviously we are preventing de-facto standard portable programs from
> compiling on at least some of the NetBSD platforms.

And what does the use of the 'unix' definition uniquely identify?

Existence of ioctl()?  Maybe (but i'd guess that systems which don't
define unix also have ioctl), but definitely not specific ioctls.

While defining it may cause you warm fuzzies, what positive effect
does it actually have?  Yah, old pieces of software -- WHICH WILL IN
99.99% OF ALL LIKELYHOOD WILL NOT PORT CLEANLY ANYWAY -- will not port
to NetBSD without the addition of -Dunix to their Makefiles.  So be
it.  That's cake compared to the other changes in interfaces which
came along with 4.4BSD and then were made in NetBSD ("follow the
bouncing sys_errlist!"), and to other changes necessarily for multiple
architecture (e.g. alpha) support.


The right direction to go is to kill -Dunix it everywhere, not to
resurrect it.  It's largely meaningless in this day and age, and
having it present doesn't actually address any significant portability
problems.




cgd