Andrey Chernyshev wrote: >> I didn't find the exact reason why this happens, looks like a drlvm ant >> scripts work differently. > > It could be a side effect of the recent adoption of DRLVM build for > classlib binaries.
Most likely. :) > The trick is that drlvm should put it's own > hythread library into the deploy JRE. Yes. > Before that change drlvm wasn't building the original hythread library > at all, but now libhythr.so is copied from the class libraries into > the deploy directory along with all other native class libraries. > > There could be two ways to resolve it: > > (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a > filter which will will exclude hythr from copying; Sure. > > (b) More graceful fix - split the "process.components" target in > build.xml into compilation of the components and their copying into > deploy directory, and then update the dependencies order for the > "build" target to make sure that class libraries are always copied > first and then the compiled drlvm binaries are copied second, > overwriting the classlib binaries if needed. No - this is too random for my taste. I'd rather see things be very deliberate, such as not have the name clash. Then it's harder to screw up. > > I would prefer to do (a) for now since these kind of dependencies > between classlib and drlvm are supposed to be handled by the top level > build anyways. I don't think we want to put too much intelligence into the top-level build. each part of the top level build, be it drlvm, classlib, jchevm, classlibadapter, whatever should provide it's artifacts in an agreed-upon location/structure, and the top level just copes from there. We need to make sure that we're order independent. This way, adding things to the 'federation' is easy. geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
