This is the mail archive of the
mailing list for the GCC project.
Re: PATCH for java.nio FileChannel and MappedByteBuffer
Tom Tromey wrote:
Per> Using include files *is* the standard approach in the GNU toolchain.
"Per" == Per Bothner <firstname.lastname@example.org> writes:
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.