The waltz with ninjas toward portable Ninja build systems
I have a project I need to build on Windows and Linux. Having an easy build is really easy thing to solve when you have full control over the build system, but if you have dependencies then you have a problem.
Many people expect you to just use their build system and let it be. It's fine for popular distributions of Linux, but on other platforms you can prepare for difficult builds that require lot of manual work before you get it straight.
Lately I've seen an interesting trend though. It goes like this:
- The build system has been written in Python 2.7
- The build system can produce
build.ninja
This is the outcome of Python being largely unchanged for a long while now. Python 2.7 is the most usable and most stable standard for writing scripts that I've ever met.
Loosely faithful to all meanings of the name 'Ninja', the build system puts the plan into an action. Sooner than what it would occur naturally.
Ninja is an improved form of 'make' utility that expects you to construct build scripts with a tool, ensuring that the script itself can run as fast as possible.
It has infiltrated everywhere
Anything of this wouldn't be interesting if you couldn't use Ninja to build your dependencies but, faithful to its name, it has infiltrated everywhere.
Zlib uses cmake to build and libuv uses GYP. Both of them
can produce build.ninja
. Doing it through the Ninja was
the most reliable way to get these dependencies build in all
of my systems.
Build systems have been very despicable for a while, but at least now you can be despicable back and rely on ninjas to get your binaries.
Contracting a Ninja
In my project I ended up to building a Ninja rather than asking the user to fetch it:
git clone git://github.com/ninja-build/ninja.git -b release
python configure.py --bootstrap
This is sufficient to get it. I am satisfied.
If I had a library that is itself a dependency not usable by a nontechnical user, It may be the best tactic to let the user fetch a Ninja.
The Ninja build system manual helps with understanding the files themselves.
Outcome
Thanks to Ninja I no longer need to rely on distributing the dependencies as binaries on Windows. This makes it more uniform to compile my project on Linux.
To build from source, I can tell the user to fetch:
- 32-bit python 2.7 installer
- Microsoft Visual C++ Compiler for Python 2.7
- Git for Windows
Then I can ask them to open the Visual C++ 2008 command prompt and run the commands:
git clone git://github.com/cheery/lever.git
python setup.py build-local
python setup.py compile
The same commands already work on Linux. On Windows I have to resolve some bugs and then it will work there as well.
Update: Oh damn. They need VC2015 to compile. I still need to bundle binaries for Windows.
Update 2: It works after all! I have to use shared libraries on libuv that compiles on VC2015.