harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy,Jing Lv" <firep...@gmail.com>
Subject Re: [build] Merging back changes from my test branch
Date Thu, 06 May 2010 02:48:42 GMT
Hi,

    That sounds great Mark! I was always suffering from the long-time build,
this will help a lot.

2010/5/6 Mark Hindess <mark.hindess@googlemail.com>

>
> After watching our build on some of the older laptops in use at the
> Open Source Jumpstart, I decided that the inefficiencies of our build
> were overdue some attention.  I created a new branch:
>
>  https://svn.apache.org/repos/asf/harmony/enhanced/java/branches/mrh
>
> and set about reducing resource usage and generally improving our
> builds.
>
> Currently my changes improve the federated build time (after fresh
> checkout) by 8% and the build time (after a build[0]) by 40%.  Also,
> as the build does fewer copies, the size of the resulting build tree
> is down from about 1.5G to less than 1G.
>
> The improvements to the classlib build times are 9% and 57%
> respectively.
>
> I am planning to merge my changes back to the trunk so I thought I
> should document some of the differences.
>
> The main functional change is that I have removed the 'build-java',
> 'build-native' and 'build-test' targets in the classlib build.  I've
> replaced them with properties (defaulting to true) called 'build.java',
> 'build.native', and 'build.test'.  So that:
>
>  ant build-java
>
> becomes:
>
>  ant -Dbuild.native=false -Dbuild.test=false
>
>
I am a little curious here ( sorry I am not a build-script expert), is it
possible to have another target or something, simply set the property. Take
this as an example, we make a target build-java to set "-Dbuild.native=false
-Dbuild.test=false" and then continue the original build. This shall not
break any improvement, and the user shall still be able to use a simple "ant
build-java".


> This may seem worse (in terms of typing) but it works from the
> federated build, in jdktools, and in individual modules rather than
> just in classlib.  I've not yet made the necessary changes to drlvm.
>
> I've appended a summary of other changes.
>
> Regards,
>  Mark.
>
> [0] This is the pathological case - no changes - similar to the
> typical development case where a developer will have changed one or
> two files.
>
>
> federated build:
>
>  Rename "internal" targets to begin with '-' so they can't be
>  called directly.  This should mean we are left with a smaller
>  set of API targets to support namely:
>
>    fetch-depends check-depends build clean findbugs test
>
>  This is incomplete with significant work still to do particularly
>  in drlvm.
>
>  Reduce copying in federated build by building directly to
>  target/hdk where possible.  Again this is incomplete.
>
>  Pass svn.info property down to builds to avoid repeated "svn info"
>  calls that make a big difference to build times.  It is a problem if
>  people modify versions of modules independently of the top-level but
>  I think that this has been broken for a while anyway.
>
>  Add "check-depends" target to federated build.
>
>  Fix MANIFEST.MF files to use specification version from a property
>  rather than being hardcoded to 1.5.
>
> classlib:
>
>  Remove make/build-*.xml
>
>  "ant test" is just a wrapper for "ant -f deploy/build/test/build.xml"
>
>
> jdktools:
>
>  As with classlib, add build.java, build.native, and build.test
>  properties.
>
>  Move tests to the HDK.
>
> drlvm:
>
>  Change implementation version in drlvm jars manifests to be svn
>  repository/revision.
>
>
>


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message