Message-ID: <1113213190.905.1411236491607.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_904_1607580471.1411236491606" ------=_Part_904_1607580471.1411236491606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The buildit script is a handy way to build and test the system. It= has countless features and options to make building and testing really eas= y, particularly in a multi-machine environment, where you edit on one machi= ne and build and test on others. If you really want to get the most o= f it, take a look at all the options by running:
...or read the script itself.
Here we just provide a hand full of examples of how it is often used, fi= rst for building and secondly for testing= (which includes building). Please add to the list if you have other = really useful ways of using it. In the examples below, we'll use thre= e hypothetical hosts: habanero (your desktop), jal= apeno (a remote x86 machine) and chipotle (a remo= te PowerPC machine).
To build a production image on your desktop, habanero, do the f= ollowing:
bin/buildit habanero production
bin/buildit localhost production
To build a production image on the remote machine jalapeno, do = the following:
bin/buildit jalapeno production
To build a production image on the remote PowerPC machine chipotle= em>, do the following:
bin/buildit chipotle production
Since building on a PowerPC machine can take a long time, you might pref= er to build on your x86 machine jalapeno and cross-build to ch= ipotle. In that case you would just do the following:
bin/buildit jalapeno -c chipotle production
In each case, buildit figures out the host types by interrogating them a= nd does the right thing (forcing a PPC build on the x86 host jalapeno since= you've told it you want a build for chipotle, which it knows is PPC). = ; Buildit caches the host information, and will prompt you the first time i= t encounters a new host.
If you want to specify the build fully, you can do something like this:<= /p>
bin/buildit jalapeno FastAdaptive MarkSweep
If you want to specify multiple different GCs you could do:
bin/buildit jalapeno FastAdaptive MarkSweep SemiSpace GenMS
which would build all three configurations on jalapeno.
Jikes RVM has the capacity to profile the boot image and then re-build a= n optimized boot image based on the profiles. This process takes a li= ttle longer, but results in measurably faster builds, and so should be used= when doing performance testing. Buildit lets you do this trivially:<= /p>
bin/buildit jalapeno --profile production
Jikes RVM currently has a notion of a "test-run&qu= ot;, which defines a complete test scenario, including tests and builds.&nb= sp; An example is pre-commit, which runs a small suite of pre-comm= it tests. It also has the notion of a "test&quo= t;, which just specifies a particular set of tests, not the full scenario.&= nbsp; An example is dacapo, which just runs the DaCapo test = suite (see the testing/tests directory for the available tests).
To run the pre-commit test-run on your host jalapeno just do:
bin/buildit jalapeno --test-run pre-commit jalapeno
To run the dacapo tests against a production on the host jalapeno, do:= p>
bin/buildit jalapeno -t dacapo production
To run the dacapo tests against a FastAdaptive MarkSweep build, on the h= ost jalapeno, do:
bin/buildit jalapeno -t dacapo FastAdaptive MarkSweep
To run the dacapo and SPECjvm98 tests against production on the host jal= apeno, do:
bin/buildit jalapeno -t dacapo -t SPECjvm98 production