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

[Steve Poole]

On Tue, 2011-11-29 at 15:08 -0800, Phil Race wrote:
> Flat vs Hierarchical is OK. its needless proliferation I was objecting to.
> 
> If "ifdef capability" can be used I have no issues with that either.
> 
> I suggested maintaining the name as src/solaris partly because I don't 
> believe in churn
> and am not sure what would make a better name other than src/unix .. 
> would that be OK ?

+1 for src/unix  

> You could create src/sunos for the really sunos parts ..
> Keeping the name the same also makes applying backport patches much easier.
> Well, that and of course my fingers know it very well.

> -phil.
> 
> On 11/29/2011 2:00 PM, Alan Bateman wrote:
> > On 29/11/2011 19:34, Phil Race wrote:
> >> :
> >>
> >> * 95%+ of the code will be the same across solaris/linux/etc
> >>   And remember this includes all the X11 code.
> >> * Of the remaining 5%, most of it is best dealt with via ifdef
> >>   because its a few line delta in a large file.
> >>   I'd guess 2% of the code might merit a separate source file.
> >>
> >> So whilst these may exist in ports that doesn't mean they should all 
> >> exist
> >> in mainline. I suggest to keep src/solaris (for historical reasons) as
> >> meaing "src shared across the unix/X11 family" and others in mainline
> >> only for the core supported platforms, which will add macosx in JDK 8,
> >> largely because of client code differences
> >>
> >> Ports would add their own platform dir if they need to, or add ifdefs 
> >> in src/solaris
> >> if that's easier.
> > I'm not so sure about keeping src/solaris as "src shared across the 
> > unix/X11 family", I'd prefer it be renamed to something that doesn't 
> > have "solaris" or "sunos" in the name. The reason is that keeping 
> > solaris in the name means there isn't an obvious location for Solaris 
> > specific files. If they stay in src/solaris then it means this tree 
> > requires pre-processing or filtering in the build. We do this today in 
> > several places with no consistency and it would be nice to get rid of 
> > this.
> >
> > In any case, keeping the directory structure flat as Fredrick 
> > suggested make sense to me. Whether we will actually or refactor to 
> > the point where we need sysv, gnu, etc. directories isn't clear to me. 
> > I think we would be doing well to replace most of the ifdef 
> > __solaris__ and ifdef __linux__ usages with ifdef <capability>.
> >
> > -Alan.
>