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:58:58 GMT
On Feb 4, 2008 11:34 PM, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> Hello Mark,
> Doesn't autoconf insert GPL license in the code by default, does it?
>
> Generally modularity looks tempting. I'm not yet convinced that we
> should generally move away from using APR instead of moving APR closer
> to what we want. The synergy with another Apache project seems to be a
> good Apache practice.

It sounds strange to use APR only because it's an Apache project. That
only makes sense if we have to choose between APR and a non-Apache
project.

Thanks,
xiaofeng

> Thanks.
>
>
>
> On Feb 4, 2008 6: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.
> >
> >
> >
>
>
>
> --
> With best regards,
> Alexei,
> ESSD, Intel
>



-- 
http://xiao-feng.blogspot.com

Mime
View raw message