jdk/src/solaris - time to re-visit it?
spoole at linux.vnet.ibm.com
Wed Nov 30 12:05:21 UTC 2011
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.
> 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.
More information about the build-dev