This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH for java.nio FileChannel and MappedByteBuffer


Tom Tromey wrote:

"Per" == Per Bothner <per@bothner.com> writes:

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.

Any design issue can be viewed as theoretical.  The arguments for
autoconf feature testing as opposed to platform identification
are equally theoretical.

Trying to divide the universe of targets into "Posix", "Win32",
and "Ecos" seems so obviously wrong to me, I don't understand
why you with your experience is in favor it.  I understand
the "it ain't broke, so leave it be" argument, so I'm not suggesting
rushing to remove the existing symlinks.  But new classes should
avoid symlinks, and removing the existing symlinks would be a
useful though low-priority cleanup.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]