Subject: SV4 ??

From: [email-masked] (Pete Holsberg)
Date: Mon, 28 Nov 1994 16:16:10 GMT

Pine developers: why do you put the "sv4" stuff in with the
non-ANSI group? Is there some variant of SVR4 that is not
ANSI-compatible? Eg., to get pine to build under UnixWare
(SVR4.x), I have to move the sv4.* files from the non-ANSI
directory to the ANSI directory, and edit a couple of makefiles
to activate "-DANSI".

Surely you could handle that easily enough in your
distribution???

Thanks,
Pete

---

From: Mark Crispin <[email-masked]>
Date: Mon, 28 Nov 1994 23:39:51 -0800

On Mon, 28 Nov 1994, Pete Holsberg wrote:
> ANSI-compatible?

The answer to this question is "yes"; there are SVR4 systems that do not
have C compilers which support ANSI prototypes.  A port is necessarily
limited by the worst representative of that port. 

> Eg., to get pine to build under UnixWare

There is absolutely no reason why it should matter whether or not the sv4
files are in .../imap/ANSI/c-client or .../imap/non-ANSI/c-client. The
only difference between the .../imap/ANSI and ../imap/non-ANSI trees is in
the C function prototyping and function headers.  The object files
generated are identical.  The existance of the ANSI tree is only to help
me in software development.  I'm seriously considering releasing only the
non-ANSI tree, which was done in earlier versions of Pine, to put an end
to these debates. 

Any problems you may have in building Pine under UnixWare are completely
independent of which tree the c-client sources are in.  I'm willing to
help out on figuring out what the problems you may be having, or even to
build a new UnixWare port if it is necessary to make it plug&play for
UnixWare.

But please, let's all accept that: the SV4 port is non-ANSI for a reason,
it is not to insult your C compiler, it doesn't make any difference in the
resulting binaries, and the resulting binaries are all that counts!! ;-)