On Feb 4, 2008 11:34 PM, Alexei Fedotov <[EMAIL PROTECTED]> 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 <[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 > -- http://xiao-feng.blogspot.com
