Bob!
Posted: Wed Mar 18, 2015 1:44 pm
Hi all,
In long-standing use of plain makefiles - since 2002 I've built my OSes and other projects with Make and plain makefiles - I've found out that they are unfixably broken. There are a few things that annoy me most about make, which boil down to Make not being able to handle more than one variable part of its rules, and Make not understanding what it actually makes.
The first means that any makefile that's sufficiently complex will have to invoke a recursive make to do what it wants to do - if you want to build a 32-bit and 64-bit debug and release build, you're essentially boned. (I know there's a workaround for 2 variable parts, but it does not stretch to 3 or more).
The second one is more insidious, and extends to any thing that uses make (and typically that can use make even if it doesn't!) - when you have a rule that produces B from A, and a rule that produces C from B, the build system doesn't know that after building B you should build C, even if B doesn't exist yet. Makefiles typically work around this by having you propagate this yourself, which is a perfectly fine way of doing things if you never make mistakes. Of course though, we do.
It also means that if you no longer have a source A that it does not know that the output is not needed anymore. It requires you to have an explicit forward for such inputs (so that for example your linker knows what to link in) which is tedious and error-prone. Alternatively you can make your linker input a shell wildcard or such, which leads to it forgetting inputs on build, and taking in too many outputs (stale build outputs for example) when you delete or rename a file.
Enter Bob.
Bob has been engineered to be a Make replacement. The complexity of its inputs is as complicated as your build system is - which is to say, if you have a sane build setup it is easy to make a short Rulefile for it. It allows you to eliminate nearly all duplication of rules or setup, and can be shorter than your list of projects (!) if your projects are similar in setup.
It thinks like Make does, except the other way around. Instead of "I'd like to make X, so what inputs can I take" it reasons "I have Y, so what could I build from it". It then always uses the list of virtual files that it could have - rather than the actual files that it currently has - to reason about what to further build. That does not mean that it will actually build those - it's just a possible target that you could include in "all".
It also generates a "clean" target for you - which deletes any files that are tagged as generated, and any files for which it has a build rule (ie, that it would regenerate anyway). This occasionally surprises myself when using it but it has the giant advantage of knowing that any file in your output folders must match the inputs - even if you do move around things there manually after.
It is also by default N-way multithreaded in that it runs all builds in parallel. You should never need to disable this - it's powerful enough for even generated code and tools to be taken into account so that code that may include a generated header does not build before the header is actually generated.
And then the final one - it's really damn fast. I've developed it for a proprietary code base on which the current build system takes up to 5 minutes to just look at each file and do nothing, where Bob takes about 4.1 seconds.
I've currently got it hosted on https://github.com/dascandy/bob . Feel free to try it out or to criticize it - I'm mostly looking for ways to improve it and limitations that it could work better with.
In long-standing use of plain makefiles - since 2002 I've built my OSes and other projects with Make and plain makefiles - I've found out that they are unfixably broken. There are a few things that annoy me most about make, which boil down to Make not being able to handle more than one variable part of its rules, and Make not understanding what it actually makes.
The first means that any makefile that's sufficiently complex will have to invoke a recursive make to do what it wants to do - if you want to build a 32-bit and 64-bit debug and release build, you're essentially boned. (I know there's a workaround for 2 variable parts, but it does not stretch to 3 or more).
The second one is more insidious, and extends to any thing that uses make (and typically that can use make even if it doesn't!) - when you have a rule that produces B from A, and a rule that produces C from B, the build system doesn't know that after building B you should build C, even if B doesn't exist yet. Makefiles typically work around this by having you propagate this yourself, which is a perfectly fine way of doing things if you never make mistakes. Of course though, we do.
It also means that if you no longer have a source A that it does not know that the output is not needed anymore. It requires you to have an explicit forward for such inputs (so that for example your linker knows what to link in) which is tedious and error-prone. Alternatively you can make your linker input a shell wildcard or such, which leads to it forgetting inputs on build, and taking in too many outputs (stale build outputs for example) when you delete or rename a file.
Enter Bob.
Bob has been engineered to be a Make replacement. The complexity of its inputs is as complicated as your build system is - which is to say, if you have a sane build setup it is easy to make a short Rulefile for it. It allows you to eliminate nearly all duplication of rules or setup, and can be shorter than your list of projects (!) if your projects are similar in setup.
It thinks like Make does, except the other way around. Instead of "I'd like to make X, so what inputs can I take" it reasons "I have Y, so what could I build from it". It then always uses the list of virtual files that it could have - rather than the actual files that it currently has - to reason about what to further build. That does not mean that it will actually build those - it's just a possible target that you could include in "all".
It also generates a "clean" target for you - which deletes any files that are tagged as generated, and any files for which it has a build rule (ie, that it would regenerate anyway). This occasionally surprises myself when using it but it has the giant advantage of knowing that any file in your output folders must match the inputs - even if you do move around things there manually after.
It is also by default N-way multithreaded in that it runs all builds in parallel. You should never need to disable this - it's powerful enough for even generated code and tools to be taken into account so that code that may include a generated header does not build before the header is actually generated.
And then the final one - it's really damn fast. I've developed it for a proprietary code base on which the current build system takes up to 5 minutes to just look at each file and do nothing, where Bob takes about 4.1 seconds.
I've currently got it hosted on https://github.com/dascandy/bob . Feel free to try it out or to criticize it - I'm mostly looking for ways to improve it and limitations that it could work better with.
