Re: PATCH for java.nio FileChannel and MappedByteBuffer

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi Per,

>> Per> * using cpp #include rather than symlinks for Posix vs Win32
>> Per> discrimination.
 
>> I still don't like this.  I read through your objections, but bluntly
>> I find them all a bit theoretical.  We've been using the current
>> system for 4 years without serious problems.  Any sharing issues can
>> be addressed in any number of ways, for instance `.h' files.  I'd much
>> prefer we just continue with the approach we've already got.

>Using include files *is* the standard approach in the GNU toolchain.
>Look at the gcc directory: no symlinks (except for stage-stuff).
>And it has lots of target and host dependencies.  Likewise emacs.
>The stdc++-v3 directory does use symlinks, but a different purpose
>(to create a unified include directory), not for target selection.

I can't speak authoritatively on this, but here are my two cents worth.
Note that this shouldn't be construed as a generalization of the right
thing to do with gcc as a whole, but rather, my admittedly limited experience
with libgcj.

First off, I've mentioned before that the symlink approach is the safest
way for me to guarantee that I can mess around with Win32 files and
not mess up the POSIX world. To use your patch as an example: yes,
you can argue that if _JV_WIN32_H is defined, then no amount of
messing up natFileChannelWin32.cc can adversely affect the compilation
of natFileChannelImpl.cc for the POSIX world, but when push comes
to shove, this is a harder sell than the guarantee that the two files are
100% independent.

>Trying to divide the universe of targets into "Posix", "Win32",
>and "Ecos" seems so obviously wrong to me....

For me, the crux of the matter is how different the OSes are. There is
variation among the POSIX targets, for example (HAVE_MMAP, HAVE_SYS_IOCTL_H,
HAVE_SYS_FILIO_H), but not enough to justify splitting this into separate
files. However, the Win32 and POSIX targets are different animals. Again,
taking your patch as an example, when I looked at natFileChannelImpl.cc,
the code for POSIX and Win32 was so different and there was so little shared
code, that I couldn't help wondering why this wasn't split up and put into the
OS-specific files. In this case, natFileChannelImpl.cc would have been nothing
more than a shell for the target-specific includes and then you might as
well use symlinks....

By the way, thanks for all the work you've put into this.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/