Building Release Binaries

The psol/ directory includes just the parts of mod_pagespeed that ports need in order to build. By preparing it for people we can let others build with a much simpler flow.

First we take a mod_pagespeed checkout and extract the headers and a few source files into a new psol directory. Prepare a local mod_pagespeed checkout and build it. Follow build psol from source but stop when it asks you to check out ngx_pagespeed. You'll need to change the tag in the gclient config to the one of the release you're doing. Run the build process twice, once with BUILDTYPE=Debug and once with BUILDTYPE=Release.

To check that this worked ok, run:

grep '^#define MOD_PAGESPEED_VERSION_STRING' /path/to/mod_pagespeed/src/out/*/obj/gen/net/instaweb/public/version.h

You should see that both the Debug and Release versions have the right version, which is the version you're trying to release.  If that's 1.5.27.2 you would expect to see:

/path/to/mod_pagespeed/src/out/Debug/obj/gen/net/instaweb/public/version.h: #define MOD_PAGESPEED_VERSION_STRING "1.5.27.2"
/path/to/mod_pagespeed/src/out/Release/obj/gen/net/instaweb/public/version.h: #define MOD_PAGESPEED_VERSION_STRING "1.5.27.2"

Now get an ngx_pagespeed checkout and run the trunk-tracking version of prepare_psol.sh to get the headers:

git clone https://github.com/pagespeed/ngx_pagespeed.git
cd ngx_pagespeed
git checkout trunk-tracking
scripts/prepare_psol.sh /path/to/mod_pagespeed/src/

This will create a psol directory that has headers and a few source files.

Next we need to populate psol/lib, which means building binaries.  We want to build these on a linux system running a toolchain at least as old as any we might want to distribute to. A CentOS 5 VM is good here, because that's going to be running GCC 4.1. We want both 32 and 64 bit binaries, so you need two VMs.

On each VM, build PSOL from source stopping once you have pagespeed_automatic.a. Specify BUILDTYPE=Release. If you've already done this, and are just updating for a new release of binaries, you can follow a simpler process:

$ cd mod_pagespeed/src/
$ svn switch http://modpagespeed.googlecode.com/svn/tags/X.Y.ZZ.W/src
$ export PATH=$PATH:~/bin/depot_tools
$ gclient runhooks
$ make AR.host="$PWD/build/wrappers/ar.sh" \
    AR.target="$PWD/build/wrappers/ar.sh" \
    BUILDTYPE=Release \
    mod_pagespeed_test pagespeed_automatic_test && \
  cd net/instaweb/automatic && \
  make AR.host="$PWD/../../../build/wrappers/ar.sh" \
    AR.target="$PWD/../../../build/wrappers/ar.sh" \
    BUILDTYPE=Release \
    all

Now the two VMs have all the Release binaries built. Run a bunch of scps to get them down to your system:

for library in \
    net/instaweb/automatic/pagespeed_automatic.a \
    out/Release/obj.target/third_party/serf/libserf.a \
    out/Release/obj.target/third_party/apr/libapr.a \
    out/Release/obj.target/third_party/aprutil/libaprutil.a
  do scp hostname-32-bit:mod_pagespeed/src/$library /path/to/your/new/psol/lib/Release/linux/ia32/
done

Then repeat to copy from hostname-64-bit to linux/x64.

Then on each VM, start over to make Debug builds. This is:

$ cd ~/mod_pagespeed/src/net/instaweb/automatic
$ make clean
$ cd ~/mod_pagespeed/src

Then run make again, as in the build doc, but with BUILDTYPE=Debug. Continue with the doc from there, and when you build in net/instaweb/automatic you should also use a BUILDTYPE=Debug argument with make all.

Run the same scps again, this time to lib/Debug/....

If you built this off of tag 1.2.3.4 then tar it up as:

tar -cvzf 1.2.3.4.tar.gz psol/

Now we need to test that our new psol directory works. If there isn't already a branch for tracking this release, make one and get it building against this svn tag. Then on both the 64 bit and 32 bit VMs build nginx following the installation instructions, using the release-tracking branch and the psol/ you built. Make sure it passes tests. Then repeat the building from the ./configure step, this time specifying --with-debug to make sure that the debug binaries are good too.