jdk/src/solaris - time to re-visit it?

[Phil Race]

Its tricky.

I would not gratuitously change any of the directory names, especially 
the win32 one.
There'd have to be a compelling reason.

The Linux and Solaris ports share X11 for their windowing system, but 
the OS X port
doesn't. So some mac things would go in src/solaris, as they are 
shareable, [perhaps/often
unixisms] to a very large degree but most of the new client code rightly 
belongs in a
new macosx directory.

So the name "posix" might seem the right one for "core" but as much
of what is in src/solaris is X11 and other windowing system related
and isn't defined by POSIX. And we can even use POSIX APis on windows ..

I've always thought of src/solaris as "unix" or "unix+x11" specific 
directory".

-phil

On 11/23/2011 5:33 AM, Fredrik Öhrström wrote:
> 2011-11-23 13:12, Alan Bateman skrev:
>> In the jdk repository then src/solaris has all the Solaris and Linux
>> code. Most of it is used for both platforms with a small number of files
>> specific to one or the other. I'm sure this has come up before (probably
>> many times) but I'd like to bring it up again.
>>
>> One of motives for bringing this up now is the Mac OS X port is coming.
>> It adds/changes code in src/solaris and also adds a lot of code to a new
>> tree src/macosx. Another motivation is patches from IBM folks which are
>> really just changes to workaround the fact that we've got code for
>> several platforms in the same directory. As I look through src/solaris
>> now it is clear that we have taken several approaches to this. In some
>> cases we've got Solaris* files, in other cases we rename files during
>> the build.
>>
>> The purpose of this mail is just to probe and see if anyone has thought
>> about this problem recently. I'm not suggesting anything specific except
>> to see whether it's worth thinking about how we might change this in the
>> future. I've no doubt that there isn't a perfect solution to this and
>> clearly any changes will be disruptive (but there's no harm discussing
>> possible options).
> I have.... no suprise there I guess ;-). If you read
> CompileJavaClasses.gmk in build-infra/jdk7/jdk/make
> you can see the hoops we need to go through to filter out platform
> specific classes in share/classes
> and linux specific classes in solaris/classes etc etc.
>
> In build-infra we are using the variable:
>
> HOST_API
>    that can be posix or winapi
>
> code common to linux,gnu,solaris,bsd,aix and macosx should be put into
> src/posix/classes.
> code belonging to windows is put inside src/winapi/classes.
>
> (winapi was earlier named win32 but the name was changed by Microsoft to
> winapi,
> since win32 actually supports 64 bits. Perhaps in the future there might
> be some
> windows_mobile platform that also uses code inside winapi.)
>
> HOST_OS (ie PLATFORM)
>    is linux,bsd,gnu,solaris,macosx,aix etc
>    thus platform specific code is in src/linux/classes
> src/solaris/classes src/bsd/classes
>
> Do we also need the variable HOST_OS_PEDIGREE that can be?
> gnu_pg (for code shared by linux,gnu etc)
> sysv_pg (for code shared by solaris,aix etc)
> bsd_pg (for code shared by macosx,bsd etc)
> if so, such code would be placed in src/sysv_pg/classes
>
> We are not really moving any source code around in build-infra. That has
> to wait until
> the big jigsaw change. But the variables are in place.
>
> //Fredrik