harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] Should we make portlib a separate component?
Date Mon, 04 Feb 2008 22:18:59 GMT

On 4 February 2008 at 20:35, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Mark Hindess wrote:
> > Should portlib be a separate component like classlib, drlvm, jdktools,
> > etc.?
> > 
> > Currently portlib is closely associated with classlib.  It is built in
> > the same way as any other classlib module.  But really it isn't just
> > another classlib module.  It's a porting layer for classlib, DRLVM,
> > jdktools, etc.
> 
> Well it isn't today.  DRLVM and jdktools do their own thing, so it 
> really is just a factoring of the class library code.

I think you'll find DRLVM does several of its own things ;-) *and* that
one of them is portlib - see:

  vm/port/src/logger/logger.cpp

I'll comment on the rest of your message in the morning.

-Mark.

> > It is suppose to have a well-defined API ... but we changed the API
> > without a second thought when the patch for HARMONY-2236, for example,
> > was committed.  I'm under no illusions that having portlib as a separate
> > component will stop this happening but I think it would help us think
> > about it a little differently.
> 
> I don't see why this a problem.  We have control over both sides of the 
> API boundary, so changing the API to suit a usecase better is fine, 
> provided the implementation and its usage is changed simultaneously -- 
> and it was.
> 
> We don't promote the portlib APIs for our end users to use.  If we did 
> then of course we would have to be more careful.  Even internally, like 
> the VMI, we are careful when there are internal users.
> 
> > It would also enable us to apply versioning (branching/tagging) to
> > portlib separately from classlib which in turn would allow us to
> > manage changes to the API more easily.  Classlib/DRLVM could make
> > compile/runtime decisions based on the version of the portlib API that
> > is found.
> 
> I see what you are saying, but again, I'm yet to be convinced there is a 
> problem being solved here.  Why not also version control the hycommon, 
> hythread, etc internal APIs too?
> 
> > Separate versioning of this component should make it easier to make
> > changes and extend the portlib to cover additional requirements.  For
> > example, to better support DRLVM, particularly if it moved away from
> > using APR which I seem to recall was mentioned (again) recently.
> > 
> > It would also give us the flexibility to choose to have portlib use a
> > different build mechanism in future - such as autoconf - if we decided
> > that was more suitable for a pure native code component.
> > 
> > Comments?
> 
> I don't have a strong objection to moving it out to a 'top level' 
> component -- it just seems premature when there is no pressing need to 
> do so.  If somebody declared a porting problem, or DRLVM gurus said they 
> want easier access to use it then sure.  Perhaps there is a driver that 
> I'm not seeing here.
> 
> It sounds like it is just a move within the project, not a re-architecture.
> 
> Regards,
> Tim
> 



Mime
View raw message