include file problems

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

>>>Much of the basic code doesn't change in the libraries... you'd be able to
>>>forget about those bits of code.
>>
>>Unfortunately this isn't true.  I wish it were.
>
>Really? What about all the startup code, the GCC library stuff (all those
>annoying little source files for adding subtracting etc) I'm sure it would
>be a good idea to get those out of the way.

crtinit.c changed in PL39, and some of those annoying GCC files
changed in PL38.  *All* of those annoying GCC files (actually every
bit of assembler source in the library) will soon be converted to
motorola syntax (to be translated at compile time by asmtrans).
Nothing is sacred.  Getting them "out of the way" would just mean
another directory to produce patches for and so on.

>>>Also... you could farm out sub-sections of the libraries to subsiduary
>>>maintainers who could generate unified patches for those directories.
>>
>>...And then have a real headache when some change has to be
>>coordinated between seven different people.  Not to mention how
>>difficult it would be to get people to send patches to the correct person.
>
>It would have to be thought out well, but I don't see it as being as bad as
>you paint it. As long as the divisions were logical and well defined you'd
>merely be a librarian gluing the sections together into the complete
>library and acting as a clearing house. If anything your job would be less
>taxing and less time consuming, you'd have less patches to apply, merely one
>from each sub-section every so often, which you'd pass onto the other groups
>so they could keep their libraries up to date.

Actually, sorting through patches and applying them after deciding on
correctness and desirability takes at most 10% of the time I devote to
the library.

The other 90% is spent making my own changes (maybe 10%), and
producing patches (at least 60%) and compiling and testing (maybe
20%).

It currently takes about 10 hours for me to produce a distribution
(thankfully only about 1 hour need to be spent at the keyboard in
total since I've automated most of it recently).

Splitting the library up would just make producing distributions more
tedious (waiting for sub-maintainers to get in sync, checking their
changes, arguing with them when I disagree, and so on.)

>>>At the moment C libraries for the Atari computers are a hotch-potch mess. We
>>>need to unify them and standardise asap IMHO so code will be able to be
>>>compiled using any of the compilers without hassle, at least the free-ware
>>>compilers. Maybe we could get the commercial compiler producers to get in
>>>line too.
>>
>>I agree.
>
>At least there's something we agree upon! :-)
>
>>>(By the way.... has anyone fixed scanf() yet? :-))
>>
>>I don't even know what's wrong with it, besides the fact that people
>>say it fails some tests.  Now if I could find those tests...
>
>Hmm.. it's rather broken... I can hack it to pass the GNU tests but it still
>screws up big time when used in conjunction with yacc generated parsers and
>the like. I think we need a complete replacement, the current version is too
>broken to be economically fixable. Maybe we could use the one out of the GNU
>library or maybe the BSD one.

I'd rather not use the GNU one as it is not public domain.  I'd be
willing to distribute the gnu version as gnu-scanf.c with a
compile-switch in the Makefile to select which one you want.  But
fixing the existing one is still a good idea.

>>The first four are all in the domain of the socket library, which is
>>not part of the mint library.  Maybe it will be at some point, i'll
>>worry about it then.
>
>I think it's best to take a strategic view early so you don't go down a
>dangerous path which could lead to problems later.

There's nothing in the current organization that would prevent us from
adding appropriate directories later on. I really don't see a problem
here.

>>There is no posix/*.h.  All posix-required headers are in the main
>>include directory.  What would we gain by having posix/stdio.h,
>>posix/unistd.h etc.?
>
>There are some parts of the POSIX definition which contradicts the ANSI
>definition.. this is why we may need suplimentry libraries and header files.

Most conflicts can be resolved with judicious use of the _POSIX_SOURCE
and __STRICT_ANSI__ macros.  Admittedly I've been a bit sloppy about
this as I don't own a copy of either standard (now you know what to
buy me for Xmas).

>It all depends, of course, as to whether there will come a time when we need
>a number of versions of routines, one which is the "common" version and one
>which is POSIX complient. To use the POSIX version you'd include the posix
>headers and link with -lposix.

I'm doing everything I can to avoid this as I'd really rather not have
to deal with all the new .olb's (posix16, bposix, etc).  Of course if
it becomes necessary it'll happen, but the headers can still remain
unified because all posix source code is supposed to #define
_POSIX_SOURCE.

cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu