Re: [general] Should we make portlib a separate component?

[Mark Hindess <ma...@googlemail.com>]

On 4 February 2008 at 18:34, "Alexei Fedotov" <al...@gmail.com>
wrote:
> 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.

Regards,
 Mark.

> On Feb 4, 2008 6:18 PM, Mark Hindess <ma...@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

Re: [general] Should we make portlib a separate component?

[Alexey Varlamov <al...@gmail.com>]

> > 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?

Hmm, it might be easier to advance Harmony portlib to separate
(sub)project as alternative to APR.

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

There is one more dependency on APR existing in DRLVM, it is log4cxx.
Anyway, I doubt we can afford moving from APR in near future, benefits
are not so evident to force this task.

--
Alexey