harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [general] Should we make portlib a separate component?
Date Mon, 04 Feb 2008 15:34:08 GMT
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.

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

Mime
View raw message