Re: include file problems

[Stephen Usher <Stephen.Usher@earth.ox.ac.uk>]

>>Yes it would... to begin with at least. Once the major reorganisation had
>>been done it would be far easier to maintain. It would also allow the
>>complete merging of the TOS and MiNT libraries for all compilers into the
>>one directory tree if it were a join task taken on by all the maintainers.
>
>It would be a pain in the beginning, and continuously.  I have enough
>trouble as it is trying not to lose patches.

I understand this problem! :-)

>The merging of the various libraries is being worked on (or at least
>Leif and I have been discussing how to merge the Lattice stuff into
>the main distribution.)  Organizing the files into different
>directories doesn't make this task any easier.

If it were done correctly it probably would, you might start being able to
see the wood 'cos there'd be less trees.

A basic split would be:-

	startup code
	compiler support
	basic os (low-level) functionality
	Unix/Posix compatability (built on top of the basic os part of the
		library.
	
>>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.

>>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.

>>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.

>>None other than it's a complete mess with everything just thrown into the
>>same directory! We're going to have sub-directories for a whole lot of new
>>stuff once the socket and other stuff is fully integrated.. ie. <un/*.h>,
>><net/*.h>, <netinet/*.h>, <protocols/*.h> etc... oh and I forgot..
>><posix/*.h>.
>
>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 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.

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.

>--
>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

Steve

-- 
---------------------------------------------------------------------------
Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).