Please see earlier blog postings about setting up chroots (and semi fake ones) for Shoes.
Now that I can cross compile Shoes and build installers for Linux 64 bit, 32 bit and raspberry, I need to automate the building even more. I’m almost finished with Shoes 3.2 so I wanted to build a beta 2 and I want to build all of them, once week if I don’t get around to doing it sooner. Upload them to a website is still a manual process, for good reasons,
In Linux, that needs cron and a working email smarthost so it emails me the results of the build. Email configuration for a smart host isn’t that hard. Just a Google search away. It might take a few times.
So I start with a couple of entries in my crontab.
# Update (apt-get) chroots
00 7 * * sun /home/ccoupe/bin/update-chroots
# build binary shoes one a week
30 7 * * sun /home/ccoupe/bin/build-shoes-all
That says on Sunday morning at 7:00 cron fires off a script update-chroots and at 7:30 it launches the build script. The update-chroots is not particularly clever. It just does an apt-get update (I have to be the root user though and the schroot configuration has to allow me to do that) Here’s the update-chroots script:
schroot -c debx86 -u root -- apt-get -y update
schroot -c deb386 -u root -- apt-get -y update
schroot -c debrpi -u root -- apt-get -y update
Just login into the chroot as root and run apt-get. The build-shoes-all is equally not very impressive.
# Build all binary variations of shoes. This runs under
# my crontab so user name may not be set up for chroot
schroot -c debx86 -u ccoupe -- ~/bin/build-shoes-x86_64
schroot -c deb386 -u ccoupe -- ~/bin/build-shoes-i686
# raspberry doesn't use chroot for shoes, just for the deps
Instead of running the apt-get command in the chroot, I run a script in the chroot. Since the raspberry build doesn’t run in a chroot I just run directly. Of course the build-shoes-xxxx scripts are very similar because Shoes is easy to compile when everything is setup correctly.
It all makes sense but this is a gotcha that I’ll talk about after you look at the files.
echo "Build Shoes X86_64 for Linux"
ls -ld pkg/*-x86_64.run
echo "Build Shoes i686 for Linux"
ls -ld pkg/*-i686.run
echo "Build Shoes raspberry pi for Linux"
ls -ld pkg/*-armhf.run
That’s pretty simple, right? I edited my .bashrc and put the ~/bin directory in the PATH and I can run build-shoes-all or the individual builds from the command line or cron.
Did you forget the Gotcha comment above?
When you switch to a chroot it screws with the environment variables – PATH being the important one. It just has to. What isn’t removed in my chroot PATH are entries for rvm which won’t work in a chroot. Remember, to build Shoes in a chroot we only need a ruby that can run the rake commands. We don’t care if it’s Ruby 1.8.7 or 2.1.1 or in between.
We have to set the PATH inside the chroot to something minimal w/o rvm frills. Inside schroots, my HOME dir
/home/ccoupe/ is available, so I have another script in ~/bin/bash-chroot
All we have to do is sweet-talk schroot into sourcing that file. What I am about to tell you, you need to understand that you can trash your login if you make an error and don’t know what to do about it. I’m running Ubuntu 13.10 and my [s]chroots are debian 7.2 (and the raspbian variation). Copy your .bashrc to .bash_profile. Edit .bash_profile and at the end where you’re supposed set to the PATH your way source ~/bin/bash-chroot. My .bash_profile after the copy had this at the end:
Just replace that with
It works for me in the Debian 7.2 chroots. It doesn’t work on my raspbian chroot but since I don’t build raspberry Shoes inside the chroot I don’t care. Diminishing returns and all that. No doubt someone out there thinks it would be more elegant to use real virtual machines or building in the cloud. IHO, that’s overkill with diminishing returns for something as simple as Shoes but you can draw your own line between elegance and pragmatic.
I’ll add some build-shoes-xxx scripts for MinGW (native widgets) and MinGW (Gtk2) but you can see how trivial that will be.
FINALLY, I want to mention that I’ve disturbed the force by modifying app.yaml to have major-minor-tiny version numbers. Mine looks like this:
Notice how I’ve set tiny: ‘b2’ –> beta-2. Soon it will be ‘RC1’ and then final ‘.1’. Coming Soon. That’s how I want to control the version numbers. Not with ENV variables I’ll forget to set or don’t exist in an new terminal.