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

[Jonathan Gibbons]

At the risk of including Yet Another alias, you should include 
build-infra-dev at openjdk.java.net, for the team working on the new build 
system.

-- Jon

On 11/23/2011 06:40 AM, Dmitry Samersoff wrote:
> Alan,
>
> I'd thought about it couple of times (actually, every time i touched
> networking code)
>
> Unfortunately there is no simple solution because lots of code has huge
> common part and small platform specific function on top of it.
>
> Also with a course to expand platform coverage it's possible to end up
> with a chain {common posix code}, {common bsd part}, {mac os specific part}
>
> On my opinion more or less complete way is:
>
> 1. Create os/posix directory
>
> 2. Create set of subfolders as necessary
>        os/posix/{solaris,linux,bsd ...}/{macos, openbsd, ... }
>
> 3. Change a build system to link all necessary files to
>     build/src directory during ./configure step to simplify
>     makefiles and avoid build time name clashes.
>
> 4. Revisit the code to get rid of #ifdef Platform
>
> -Dmitry
>
>
> On 2011-11-23 16:12, Alan Bateman wrote:
>> 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).
>>
>> -Alan.
>>
>>
>