21–30 of 33 posts
I've been recently using Tup [0] with great success in a project. It is interestingly different from other build systems in the sense that it defines dependencies in the opposite direction (from source file to product, not the other way around). It is incredibly fast and simple. [0]: http://gittup.org/tup/
Makefiles are of course a bit limited compared to shell scripts, but you can do a lot with implicit rules, static pattern rules, second expansion, call and eval, etc.
Goal The user is supposed to be never needing to call clean goal. Does this track build tools also? If you upgrade a compiler and some intermediate binary format changes, will it automatically clean up those stale files?
wget --no-check-certificate https://... - | sh Might as well not have that https in there at all... sigh.
I've always wondered why rake isn't more popular. It's very make-like and simple, but with the advantage of a fully-featured scripting language. https://github.com/ruby/rake
This is similar to what I wrote at work on and off over the last couple of months, replacing a build system using recursive Makefiles. Due to the way our product is composed I ended up adding support for building static libraries, programs, RPMs and documentation. With full support for dependencies, meaning if a source for a library is changed, the library will be rebuilt, programs that links against it will be re-li…
As for paper - I believe it's "Recursive Make Considered Harmful" - I read it, it's great. Was one of the main motivators during build system rewrite.
I've always wondered why Shake[0] wasn't more popular. Anyone not like Shake or know why others don't, or is this just a case of not being known? 0: https://github.com/ndmitchell/shake
In this particular case, we would need to either build GHC from source for every user, or provide a binary compiled version for every Ubuntu version to keep providing source-level access to build system.
This is similar to what I wrote at work on and off over the last couple of months, replacing a build system using recursive Makefiles. Due to the way our product is composed I ended up adding support for building static libraries, programs, RPMs and documentation. With full support for dependencies, meaning if a source for a library is changed, the library will be rebuilt, programs that links against it will be re-li…
I ended up using $(eval ...) a lot, and turns out Make's support for it is... suboptimal. As for paper - I believe it's "Recursive Make Considered Harmful" - I read it, it's great. Was one of the main motivators during build system rewrite.
Yes, that's the paper, I was also heavily motivated by it. And when I read JDK also switched[1] to something similar, it just cemented my belief it was the right way to go, for the same reasons as for them.
I'm finding that for compiling code usually it is the configuration that makes life hard rather than the build system part. I've been using cmake [1] which makes the rules to build object files, libraries, executables pretty simple although determining and adapting to the eccentricities of any arbitrary system's environment is painful. I am also liking snakemake[2] these days for running arbitrary chains of jobs that…