harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Varlamov <alexey.v.varla...@gmail.com>
Subject Re: [general] jdktools and classlib?
Date Fri, 24 Jul 2009 05:15:31 GMT
I think Oliver has made really good argument. Once I refactored out to
common_resources quite a few duplicated build functions from drlvm and
jdktools, but somehow did not gain enough momentum to push classlib in
this direction - I guess people were reluctant to force dependency on
federated build?
I still think common_resources would be the best way to mitigate build
maintenance efforts, even more so if extended with the vision Oliver's
suggested.

Really I don't see why jdktools could get more attention if merged to
classlib. OTOH, from VM development point of view I'd be bothered with
extra build&test time of basic JRE. Surely this could be coped with
via predefined module sets, but the point is lost then.

Regards,
Alexey


2009/7/23 Oliver Deakin <oliver.deakin@googlemail.com>:
> Tim Ellison wrote:
>>
>> On 23/Jul/2009 09:43, Sean Qiu wrote:
>>
>>>
>>> Do we really need this big change?
>>>
>>> There are so many "duplicated" xml files whose original goal is to
>>> achieve modularity.
>>> So each component can be developed and tested separately.
>>> I guess that's the reason that we got so many build scripts on each
>>> modules of classlib.
>>> (It is another story whether they worked as we expected)
>>>
>>> I prefer to keep jdktools and classlib separately, it sounds more natural
>>> to me.
>>>
>>
>> My gut feeling is also to keep the class library and jdktools separated,
>> but I'll admit that it is only a gut feeling and not something I can
>> defend technically.
>>
>> If it really does make life easier for build then it is something I
>> could learn to live with.  I'd like to hear the arguments though.
>>
>
> I agree. It just feels to me like the VM and classlib are obvious "units"
> and putting the additional jre/jdk tools in with either one of them doesn't
> sit right. If our goals are to get the jdktools used/looked at more and to
> unify the build scripts as much as possible, then I would suggest improving
> the federated build for wider use.
>
> At the moment if a contributor wants to just work on classlib, they will
> probably just check out classlib trunk and build from there copying in
> whichever VM they wish to use. I think it would be better if we made the
> federated build the starting point for this kind of development and improved
> the build targets it provides so it plays nicely when working with
> individual components. For this to work we would need to allow more control
> over what source gets checked out/built/tested, so they more closely reflect
> the targets within the components - here's a few examples of what I was
> thinking of (names like hy.component are just suggestions, not really
> important):
>
> "ant -Dhy.component=classlib,jdktools populate-src" - just checkout the
> source for classlib and jdktools
> "ant -Dhy.component=classlib rebuild-native" - just clean and build the
> native code for the classlib module, and automatically populate the built
> binaries under the federated target directory
> "ant build-java" - build java code across all components. This target could
> detect which components have been checked out, much as the classlib build
> works out which modules to build automatically by checking if build targets
> exists, and only build those so that hy.component does not always need to be
> specified.
>
>
> The above is just a rough idea of how it could be done, but I can see a few
> advantages of this approach:
> 1) The federated build would get used more, giving us a more unified
> approach to building Harmony while still allowing contributors to work in
> individual areas with the same ease. This should also help remove some of
> the build script duplication across components.
> 2) The java/javaw executables could be moved to jdktools (which makes more
> sense than classlib to me) meaning that jdktools would get more attention
> also.
> 3) The common_resources directory would work for those working on the whole
> jdk and also for those just working on one or two components, as they would
> both use the federated build.
> 4) If we ever wanted to add components (for example, split portlib into it's
> own component) it would be easier managed.
> 5) If you started working on drlvm only and also wanted to make some changes
> to classlib later on, you could just run populate-src specifying the
> classlib component to check out the additional source and then carry on
> working.
>
> These are just ideas at the moment, but I can see there are benefits to this
> approach. Any thoughts/comments?
>
> Regards,
> Oliver
>
>> Regards,
>> Tim
>>
>>
>>
>
> --
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>

Mime
View raw message