On 4 February 2008 at 18:34, "Alexei Fedotov" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
