PATCH for java.nio FileChannel and MappedByteBuffer

[Per Bothner]

Tom Tromey wrote:

>>>>>>"Per" == Per Bothner <per@bothner.com> writes:
> Per> Using include files *is* the standard approach in the GNU toolchain.
> 
> In general we have different needs from the rest of gcc.  For
> instance, no other target library deals with sockets.

I don't understand this point.  The compiler has much more
complex target dependencies.

> Suppose we do a cpp-based implementation.  Then we need some way to
> select between variants.  I.e., a configure-defined macro that tells
> us which .cc file to include.  Well, any way we can define that macro,
> we can also define a shell variable to set up the symlink.

Yes, but a cpp-based implementation allows fine-grained selection
and much more flexibility.  You could easily add a macro to distinguish
Windows 95/98/Me vs Nt/2k/XP for example.  Allowing sub-variants is
trivial with cpp, but more complex with symlinks.

> Per> But new classes should
> Per> avoid symlinks, and removing the existing symlinks would be a
> Per> useful though low-priority cleanup.
> 
> This leads to the gcc maintenance problem that Zack pointed out in his
> gcc summit paper: half-finished conversions.  I've come to realize we
> only rarely do cleanups :-(

But it does get done.  For example we now compile most of gcc with
-Werror, which meant a lot of cleaning up.

I'm convinced using cpp is a technically better mechanism and more
consistent with common GNU practice.  However, I'm made my point,
I've spent enough time arguing it, and I'm not going to try to force
though my preference/recommendation - at least a few more of you have
seen the light ...

Now I need to find the correct versions of autoconf+automake so I
can check in my changes, using symlinks.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/