{"id":134,"date":"2012-01-19T17:21:33","date_gmt":"2012-01-20T01:21:33","guid":{"rendered":"http:\/\/blog.mozilla.org\/warner\/?p=134"},"modified":"2012-01-19T17:21:33","modified_gmt":"2012-01-20T01:21:33","slug":"improving-the-pynacl-build-process","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/warner\/2012\/01\/19\/improving-the-pynacl-build-process\/","title":{"rendered":"Improving the pynacl build process"},"content":{"rendered":"

I’ve been hacking on my copy of pynacl<\/a> this week. pynacl is a set of Python bindings to the NaCl cryptography library<\/a> (by djb and friends). The bindings, first written by Sean Lynch<\/a> and then picked up by “k3d3”<\/a>, are great. They even support py2.6 through py3.2.<\/p>\n

But actually building them is a hassle, because the NaCl build process is so idiosyncratic. It consists of a 500-line undocumented shell script named “do”, and running it gets you 25 minutes of 100% CPU that executes in stony silence (all progress messages are redirected to a logfile). If you can wait that long, and think to explore the directory afterwards, you’ll be rewarded with a build\/HOSTNAME\/ directory that contains a libnacl.a and a set of header files that are pretty easy to use. What’s actually going on behind the scenes is that the script is exhaustively compiling and testing a large matrix of compiler flags (-O vs -O3 vs -O3 -funroll-loops), ABI variants, and alternative implementations. The goal is apparently to:<\/p>\n