harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [general] Should we make portlib a separate component?
Date Tue, 05 Feb 2008 01:56:42 GMT
I fully agree with this proposal. It makes at least a common native
resource manager easier for native memory, file handles, etc.


On Feb 4, 2008 11:18 PM, Mark Hindess <mark.hindess@googlemail.com> 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.
> 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.
> 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.
> 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?
> Regards,
>  Mark.


View raw message