build system heaven

Absolutely bloody beautiful.

I have now two scripts, both run on Linux but one targets Linux and the other Windows. I’ve spent the day getting the Windows build working, and now it does; the VM starts up, the build iterates through all variations (IA64, x64, debug, release, coverage, debug, release, etc, etc, etc, etc), and runs the test on release builds. No benchmarks, because it’s a VM.


I produced a 7.0.1 and 7.1.2 with the liblfds build updated to match the 7.2.0 build – necessary for libbenchmark to build, since it has an embedded copy of 7.0.x and 7.1.x.

The Linux version runs over all the Linux hosts – x64, MIPS32, ARM32 and ARM64, and does the same. Gnuplots made by the benchmarks are brought back to the host.

The only problem now is that the GCC on ARM64 doesn’t understand -march=native, so the make fails.

This actually touches upon me needing to compile every released version of GCC On each platform, and having the build system use them all.

That’s the next work.

After that, I need to get Bugzilla working again, which means doing something about the web-server, since nginx doesn’t support CGI.

Unexpected behaviour from Gnuwin32 gnumake and tar on Windows

Gnuwin32 gnumake does not on Windows support single backlashes as path seperators when being called with -C from inside a makefile.

So – if you have a makefile, and from inside that makefile you call another makefile, and you are in that call using -C (change directory), that inner make call will fail because it does not understand the path to -C. I think it’s probably treating the single backslashes as escapes. Single forward slashes work, as do escaped backslashes.

However, if you run that inner make directly from the command line, with single backslashes, it works.

Gnuwin32 tar seems to be randomly dropping file suffixes on Windows. The tar is made on Linux, sftp’d to Windows, then if I list it, about one in ten files is missing it’s suffix, which for liblfds means usually .c or .h, which means of course that the makefile falls over because it can’t find the files.

Going to try using zip instead. Compression sucks, but hopefully it’ll work.

Bleah, Windows

Getting code to work on Windows as well as Linux absolutely butchers what was previously simple, elegant code.

All the messing about with different commands, with different dir seperators, hell, with different bloody paths even through SFTP – “/tmp” on Linux, “/C/Tmp” on bloody Windows. Vomit.

Winodws also totally ballsed up its build config. On Linux, build config is completely within the makefile; you need to have the compiler on the path, but that’s it. On Windows, you have to run a special batch file first, where the arguments to that batch file *depend on the type of build* – debug, release, which CPU, which Windows version…

So the platform code needs to know what the target is, to configure itself properly. Vomit.

In other news, at work today, I spent nine hours failing to set up Go with Protobuffers. I had the feeling I didn’t like Go, because it forces opening braces on the same line as the if/while/etc, which I can’t read and which should *NOT* be forced on the coder. Today I discovered, after nine hours of utter frustration, that indeed, I do *not* like Go. Now I know for sure. I never did get it working with protobufs. Slogged through idiotic problem after problem and in the end, protoc was producing output which contained circular dependencies (the output file imported itself).

Build system update

More good stuff.

Have implemented the python functions (using vboxmanage) to start and stop VMs (where starting means getting the guest IP and then waiting until you can see the SSH server is responding).

At this point I’ve discovered a design flaw. I had thought I could now use SSH, SFTP and make on all platforms – which is to say, including Windows (which is what I’m using the VMs for).

This is not in fact the case. Windows needs a batch file run before the C build environment is ready. What’s worse is that it takes a bunch of args which vary depending on the target processor and operating systems – and you’ll note in that I didn’t think about cross-platform builds. The build system supports processor types, but it doesn’t (currently) support multiple *operating system type targets*.

Windows being a complete PITA again.

So too sleepy now to do more tonight. Did what I wanted to do, which is get VM startup/shutdown going.

Build system update

It’s going very well.

I had to do a fair bit of work on the library itself to get it back into fully compiling shape, for the tests and benchmark, and the two SMR methods.

So I now have a build system which will build on every Linux platform, over every build variant, run the tests and the benchmarks, and pull the gnuplots back to the originating system and convert them to PNGs.

What I need to do now is;

1. get all the version of GCC compiled on all platforms and add support for changing GCC version (so then all the Linux verions will build over every released version of GCC)

2. set up the Windows VMs with an SSH server, then figure out how to use vagrant to start/stop the VMs on demand, and then figure out how to get builds going on the Windows platforms

Build system progress

Looking good.

Have the three dev boards hooked up and ready to roll (arm32, arm64, mips32).

The build system knows the platforms it has, and how to get files to them and build on them; and it knows the targets for liblfds720. I’ve been building successfully on arm32 but I ran into a problem on the arm64 platform, the GCC (4.9.2) there doesn’t understand “-march=native”. This was a surprise.

In fact, “native” hasn’t always been present historically, even though I expect it with 4.9.2, so it’s a problem I need to address anyway.

I think what I need to do now is build every GCC version on each platform. I haven’t yet mastered building glibc, but even if it’s every GCC with current glibc (hmm, assuming that *can* work) then at least I should get past this wierd (?) GCC compiler on arm64.

build system progress

Happy joy!

Written platforms.json and targets.json, wrote the Python to export from SVN, make a tar.bz2, sftp to a remote host and then make; found my first bug, too! “-mcx16”, which is an Intel specific flag for GCC, throws an error as an unrecognized option when using GCC on ARM32.

Once the build system is up, I then need to get back to building every version of GCC on every platform, so I can compile with the lot.

After that, clang.

Actually the more-fun bit will be using vagrant to run VirtualBox VMs, and configuring Windows to accept SSH/SFTP.

Build system OTW


Finally – writing a build system for liblfds.

I know there are plenty of build systems out there. I normally find trying to figure out how to make an existing build system work for your own source code is more work than writing your own build system from scratch.

It’s written in Python. There’s a “platforms.json” in the build system itself which describes all the platforms available – which is to say, the compilers they offer, which processor type, IP address, etc.

There’s a “targets.json” in each entity which is built, which describes the platforms each build directory supports (there’s one build directory for each distinct set of build files – i.e. Makefile for GCC, Makefile for MSVC, WDK 7.1 build files, etc). So this would indicate the compilers which can be used, the processors, hosted or unhosted platforms, makefile targets, etc.

It’s assumed everything has a gnumake makefile (even if it’s just a curtsey makefile, which calls a different build system) and that I can use SSH/SFTP to get files in/out and issue commands.

DWCAS bug fix – “new” 7.1.1 released

If you downloaded 7.1.1 prior to 21:50 GMT+1 22nd Feb, please download it again.

One of the bug fixes was for DWCAS with GCC >= 4.1.2 and less than (I can’t type the less than symbol – wordpress in its awesome majesty doesn’t escape it, and it totally breaks all following formatting…!) 4.7.3. This platform is still not available for testing – a **lot** of work has gone into learning how to build GCC and glibc, to get access to all GCC versions, but that has not yet been successful.

There is a script which converts liblfds version “n.n.n” to “m.m.m”. This script was run, *and then the DWCAS macro was added in*… but with the 7.1.0 verson numbering, and this was not noticed.

Result – the macro doesn’t exist, so the arguments end up being a comma separated list of variable names, and of course this doesn’t work as expected!

Rather than making a whole new release for this, since the original has only been out for two days, 7.1.1 has been re-released.

This whole thing totally sucks. Obviously it’s well understood that if something isn’t tested, it doesn’t work; but there’s no obvious way to get hold of that test platform.

The work to get GCC and glibc built has to continue – but this is a nightmare task, truly one of the very worst things you could imagine, which is why after six weeks of non-stop work it still isn’t complete.

If you need to check which “version” of 7.1.1 you have, look at the file “liblfds7.1.1/inc/liblfds711/lfds711_porting_abstraction_layer_compiler”. Look at line 322. If you see “LFDS710_PAL_ATOMIC_DWCAS” you have the broken version. If you see “LFDS711_PAL_ATOMIC_DWCAS” you have the fixed version.

7.1.1 is out

As subject.

If you use the unbounded/many/many queue from 7.1.0, upgrade for a bugfix. See previous post for an explanation of the bug and why it was not found by the test suite.