Hi Ken. I've checked in a rough script that builds OpenEmbedded inside the cbuild Makefile-based auto builders.
To run it yourself: * bzr branch lp:cbuild * cd cbuild * cp oecore.mk lib * mkdir -p slaves/`hostname` * cd slaves/`hostname` * make -f ../../lib/oecore.mk
It's a Makefile which runs locally or remotely. Everything is under cbuild/lib. The steps are driven by steps.mk which use stamp files to see what is finished and what needs running. The normal steps are configure; build; install; testsuite; run. I've split the build and similar steps into one per architecture and added a ping to the scheduler (http://ex.seabright.co.nz/helpers/scheduler) between each one as it will take some time. Logs end up in gcc-native/*.txt.
To toast everything, do 'rm -rf gcc-native results'. The top level build directory is $LBUILD (gcc-native/oecore). The variant build directory (think -O3 vs -O2) is $VBUILD (gcc-native/oecore/$variant). The architecture directory is $VBUILD/$arch. I've left $ARCHITECTURES and $IMAGE as fallbacks so they can be overridden by the incoming job.
You should implement 'get-sizes' so we track the final image and package sizes.
I'd add a patch-% rule for any architecture specific patching such as using the vexpress-a9 model. Use patch-% as the fallback and the specific patch-arm for ARM specific. Add it as part of the configure.
It fetches a snapshot of OpenEmbedded and bitbake. The following are snapshotted on change: * kwerner/meta-linaro * openembedded-core/denzil
and end up at: http://builds.linaro.org/toolchain/snapshots/
We don't want download problems stopping us from running. The script uses my normal tactics: * Everything over HTTP * Use a in-network proxy, set in ~/.wgetrc * Pull from a mirror first or only (http://builds.linaro.org/toolchain/misc/mirror/openembedded/)
Install polipo and echo http_proxy=http://localhost:8123/ > ~/.wgetrc. I've seeded the mirror. We should keep track of any extras needed such as due to other architectures.
BTW, I'm wondering about doing the build in zram backed ramdisk. Might speed the build and not wear the build disk out.
-- Michael
On 05/10/2012 04:27 AM, Michael Hope wrote:
Hi Ken. I've checked in a rough script that builds OpenEmbedded inside the cbuild Makefile-based auto builders.
To run it yourself:
- bzr branch lp:cbuild
- cd cbuild
- cp oecore.mk lib
- mkdir -p slaves/`hostname`
- cd slaves/`hostname`
- make -f ../../lib/oecore.mk
It's a Makefile which runs locally or remotely. Everything is under cbuild/lib. The steps are driven by steps.mk which use stamp files to see what is finished and what needs running. The normal steps are configure; build; install; testsuite; run. I've split the build and similar steps into one per architecture and added a ping to the scheduler (http://ex.seabright.co.nz/helpers/scheduler) between each one as it will take some time. Logs end up in gcc-native/*.txt.
To toast everything, do 'rm -rf gcc-native results'. The top level build directory is $LBUILD (gcc-native/oecore). The variant build directory (think -O3 vs -O2) is $VBUILD (gcc-native/oecore/$variant). The architecture directory is $VBUILD/$arch. I've left $ARCHITECTURES and $IMAGE as fallbacks so they can be overridden by the incoming job.
You should implement 'get-sizes' so we track the final image and package sizes.
I'd add a patch-% rule for any architecture specific patching such as using the vexpress-a9 model. Use patch-% as the fallback and the specific patch-arm for ARM specific. Add it as part of the configure.
It fetches a snapshot of OpenEmbedded and bitbake. The following are snapshotted on change:
- kwerner/meta-linaro
- openembedded-core/denzil
and end up at: http://builds.linaro.org/toolchain/snapshots/
We don't want download problems stopping us from running. The script uses my normal tactics:
- Everything over HTTP
- Use a in-network proxy, set in ~/.wgetrc
- Pull from a mirror first or only
(http://builds.linaro.org/toolchain/misc/mirror/openembedded/)
Install polipo and echo http_proxy=http://localhost:8123/%3E ~/.wgetrc. I've seeded the mirror. We should keep track of any extras needed such as due to other architectures.
BTW, I'm wondering about doing the build in zram backed ramdisk. Might speed the build and not wear the build disk out.
-- Michael
Hi Michael,
Thanks for the skeleton. I haven't had the time to look at cbuild so far. Currently I'm using a bash script to automate the checkout, build and test of oe-core+meta-linaro: http://people.linaro.org/~kwerner/oe-core/script/build-oe-core-linaro.sh The testing part is very basic. It starts the image using QEMU, logs into the system and greps the output from the serial console.
For now, I'm focusing on backporting the GCC 4.7 support from oe-core (master) to meta-linaro (denzil) in order to support the Linaro GCC 4.7 with the oe-core release (denzil).
Regards, Ken
On 11 May 2012 04:31, Ken Werner ken.werner@linaro.org wrote:
On 05/10/2012 04:27 AM, Michael Hope wrote:
Hi Ken. I've checked in a rough script that builds OpenEmbedded inside the cbuild Makefile-based auto builders.
To run it yourself: * bzr branch lp:cbuild * cd cbuild * cp oecore.mk lib * mkdir -p slaves/`hostname` * cd slaves/`hostname` * make -f ../../lib/oecore.mk
It's a Makefile which runs locally or remotely. Everything is under cbuild/lib. The steps are driven by steps.mk which use stamp files to see what is finished and what needs running. The normal steps are configure; build; install; testsuite; run. I've split the build and similar steps into one per architecture and added a ping to the scheduler (http://ex.seabright.co.nz/helpers/scheduler) between each one as it will take some time. Logs end up in gcc-native/*.txt.
To toast everything, do 'rm -rf gcc-native results'. The top level build directory is $LBUILD (gcc-native/oecore). The variant build directory (think -O3 vs -O2) is $VBUILD (gcc-native/oecore/$variant). The architecture directory is $VBUILD/$arch. I've left $ARCHITECTURES and $IMAGE as fallbacks so they can be overridden by the incoming job.
You should implement 'get-sizes' so we track the final image and package sizes.
I'd add a patch-% rule for any architecture specific patching such as using the vexpress-a9 model. Use patch-% as the fallback and the specific patch-arm for ARM specific. Add it as part of the configure.
It fetches a snapshot of OpenEmbedded and bitbake. The following are snapshotted on change: * kwerner/meta-linaro * openembedded-core/denzil
and end up at: http://builds.linaro.org/toolchain/snapshots/
We don't want download problems stopping us from running. The script uses my normal tactics: * Everything over HTTP * Use a in-network proxy, set in ~/.wgetrc * Pull from a mirror first or only (http://builds.linaro.org/toolchain/misc/mirror/openembedded/)
Install polipo and echo http_proxy=http://localhost:8123/%3E ~/.wgetrc. I've seeded the mirror. We should keep track of any extras needed such as due to other architectures.
BTW, I'm wondering about doing the build in zram backed ramdisk. Might speed the build and not wear the build disk out.
-- Michael
Hi Michael,
Thanks for the skeleton. I haven't had the time to look at cbuild so far. Currently I'm using a bash script to automate the checkout, build and test of oe-core+meta-linaro: http://people.linaro.org/~kwerner/oe-core/script/build-oe-core-linaro.sh The testing part is very basic. It starts the image using QEMU, logs into the system and greps the output from the serial console.
For now, I'm focusing on backporting the GCC 4.7 support from oe-core (master) to meta-linaro (denzil) in order to support the Linaro GCC 4.7 with the oe-core release (denzil).
That script is epic. I think there's a good mapping to cbuild from there. Feel free to create script fragments to call from the Makefile instead of embedding everything in the Makefile itself. They may end up reusable as well.
-- Michael
linaro-toolchain@lists.linaro.org
-
Ken Werner -
Michael Hope