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 17:57:43 GMT

On 4 February 2008 at 18:34, "Alexei Fedotov" <alexei.fedotov@gmail.com>
> Hello Mark,
> Doesn't autoconf insert GPL license in the code by default, does it?

I don't think so.  Wouldn't that already be a problem if it did - since
we use apr and apr-util which both use autoconf?

Anyway, don't get hung up on that.  It was just a example in what was
intended to be a general comment about using the right tool for the job.
(autoconf might be that tool but there are other choices these days.)

> Generally modularity looks tempting.

Good.  That was my main motivation.

> I'm not yet convinced that we should generally move away from using
> APR instead of moving APR closer to what we want.

That would be a huge task and I see no sign of effort being applied to
that problem.  I'd like to be wrong though?

The portlib API is a good deal more flexible.  (Nevertheless, it might
be an interesting exercise to implement portlib on APR.)

> The synergy with another Apache project seems to be a good Apache
> practice.

I agree but I don't see anything synergistic about combining harmony
with APR.  APR is not a good fit - see discussions in the archives.


> 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

View raw message