Re: libraries

[Michal Jaegermann <NTOMCZAK@vm.ucs.UAlberta.CA>]

I think that splitting header files AND libraries into common,
MiNT specific and TOS specific is something which should have been
done a long time ago.  Actually Jwahar, Eric and me we were talking
about that some while ago but there is quite a bit of work involved
in it.  Maybe you noticed that for some while Jwahar was moving
quietly in this direction.

Still, in my opinion, a requirement for something like an explicit
#include <tos/foo.h> would be a mistake which will cause immediate
compatibility headaches, neccessity to edit sources, lotsa of
superfluous #ifdef...#endif and the like.

I think that instead we should modify a little bit an organization
and a compiler driver.  Let us assume that we have two different files
.../include/tos/stdio.h and .../include/mint/stdio.h.  In sources
one should have one, unequivocal, directive '#include <stdio.h>'.
A compiler driver (like gcc, for example) with a flag '-tos' should
search for header files like this:
  .../include/tos/,.../include, <whatever else in include path>
and with '-mint' flag like this:
  .../include/mint/,.../include, <whatever else in include path>
with a similar arrangement for libraries.  One of flags '-mint' '-tos'
could/should be a default depending on a compiler configuration.
You risk that way at most a neccessity to recompile a driver, which
is really small program and can be redone even on the smallest
machines.  So what are your comments?

I think also that LF vs. CR/LF controversy is based on a
misunderstanding.  Maybe I got it wrong, but I thought that an
original proposition was about a form in which sources and updates are
distributed.  It is true that 'patch' will barf on you (although
'patch -l' should be ok, but it may other undesirable side effects) if
you have sources in one form and diffs in another but they are easily
convertible one way or another and there is likely 1001 ways to
acomplish that conversion.  Jwahar is using LF line terminator since
he keeps and maintains library sources on a Unix machine for the sake
of convenience but this does not mean that anybody else have to do
the same thing.  (Sending them via zmodem in an unpacked form as
text files will do that conversion for you - both ways :-)).

Julian asks why DTA is named _DTA in gcc header files.  I can guess
that this was done to be consistent with a convention that
internal "vendor names" start with '_' to avoid a polution of a name
space.  If Pure C needs DTA instead this is easy to resolve by
supplying in a "compatibility" header file "#define DTA _DTA".
As for conflicts in prototypes I really cannot tell.  I have never
seen Pure C compiler and I do not know where conflicts do occure.
I can only tell that gcc headers try very hard to follow ANSI C
Standard and comparing with other "more or less" Standard C compilers
on other machines are pretty good at it.

   Michal