Mark Hindess wrote:
> On 3 July 2006 at 15:14, "Andrey Chernyshev" <[EMAIL PROTECTED]>
> wrote:
>>
>> (a) Do a quick-fix in build.xml / deploy.copy_classlib target - add a
>> filter which will will exclude hythr from copying;
>>
>> (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.
> 
> c) Call the drlvm thread library something else to avoid the name clash
> with the existing library?  (As IBM VME does with it's thread library.)

Yes

> 
>> 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 should expect the top-level build to fix any problems
> like this.  The top-level build should be completely dumb.
> 
> My preference for the top-level build to just do a recursive copy of the
> drlvm/deploy tree and the classlib/deploy tree to a top-level deploy
> tree - which means it has to know nothing about the structure of the
> deploy directories.  (And I don't think we should rely on the order
> in which the recursive copies happen - i.e. the set of files under
> deploy/drlvm and deploy/ classlib trees should not intersect.)

Yes.  That's what I just said (in a different way) in the mail I just
sent seconds ago...

geir

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to