Off topic.
I don't have any suggestion on src and make at the moment but is it good
to build platform-specific binaries into different directories and keep
the common files at a single place? If so we can create a single merged
image that is executable everywhere.
-Max
On 11/25/2011 06:59 PM, Alan Bateman wrote:
On 24/11/2011 14:39, Fredrik Öhrström wrote:
:
It would be great to do the rename. However, we should not do that
before the build-infra changes
are in place. The peculiarities of the current build have already been
worked around and the new
makefiles are useful, since it is easy to see where the warts are. Thus
when build-infra is done, we will
have a neat list of all things that needs to be cleaned up by moving
source code and platform
specific code in src/share is just one of many problems.
I was hoping that when we start incrementally moving towards jigsaw-like
structuring of the source,
we can fix this then? When we rename directories, we lose a lot of
information in the source control system.
Necessary yes, but at least we should try to do it just once.
As for the naming:
posix is the name of a standardized API to unix-like operating systems.
winapi is the name of the defacto API to windows systems.
Using two trademarks instead of the actual names of the APIs would be
silly.
And you can run posix software on Windows by installing cygwin et al,
and you
can run winapi software on Linux by installing wine. But this is not the
point,
the point is that the built jvm will run primarily using winapi, or
primarily
using posix.
No-one answered my question if we need to track the posix pedigree? I.e.
gnu, sysv and bsd?
//Fredrik
I agree it's not a good time to do the renaming but I think it's good to
discuss and think about the how we might organize the code in the future.
I don't have strong opinions on the names but "posix" doesn't seem quite
right just now as we have code in src/solaris/** that is making use of
APIs that aren't part of POSIX (I think this was Phil's point too). On
the pedigree then it might be better to cross that bridge when we come
to it, meaning that we could only really make use of it in conjunction
with refactoring work.
You are right that the peculiarities have been worked around to date but
more have been proposed [1]. Maybe it would be prudent to hold off on
these changes until the new build is in place.
-Alan.
[1]
http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001466.html
