ndmitchell / build-shootout Goto Github PK

Comparison of build program expressive power

Haskell 90.43% Shell 9.10% C 0.46%

build-shootout's Introduction

I'm a Haskell/Rust programmer who lives in Cambridge with my wife Emily and son Henry. I have a PhD in Computer Science from York University, working on making functional programs shorter, faster and safer. Since then I've worked at Credit Suisse, Standard Chartered, Barclays Bank and Digital Asset, and I currently work at Meta — but all content and opinions are my own. I'm a strong believer in the functional programming approach, finding the combination of conciseness, static-typing and testability to offer significant advantages. I've got a blog mostly about Haskell, and I'm also on Threads, Twitter, LinkedIn and GitHub. To get in touch email me at [email protected].

Open Source Projects

At work, I am a major contributor to the Buck2 build system. At home, I develop a number of open source Haskell projects, all of which can be found at my Github page or on Hackage. I welcome both contributions via pull requests and bug reports via the GitHub issue trackers. Some of my more popular projects include:

Shake - a library for writing build systems, an alternative to make.
Hoogle - a Haskell API search engine, searching the standard Haskell libraries by function name and type signature.
HLint - a tool that suggests stylistic improvements to Haskell code.

A list of all my talks and papers are available on ndmitchell.com.

build-shootout's People

Contributors

Stargazers

Watchers

Forkers

drewm1980 hesselink silky quantheory nathansgreen menify refi64 tokenrove phlogistique enfunction

build-shootout's Issues

Adding build systems where the build file has a constant name

Some build systems (most particularly Waf and fbuild) don't let you use a custom build script. In Waf's case, it must ALWAYS be named wscript; in fbuild's, fbuildroot.py. Could a way of getting around this be added to Util.hs?

Define levels of working

As suggested by @drewm1980:

Feature X works but...
11: you have to pour the blood of a freshly slaughtered chicken over
the SSD containing your build outputs
8: you have to write a program in a general purpose language just to
get your build correct, instead of some terse but intuitive DSL
7: you have to write some nontrivial shell script to set up a tree of
symlinks, hidden files, etc...
5: you have to provide a snippet of shell script instead of the nice
DSL you normally use
3: you have to manually add a special flag to each rule, i.e. ^o^
2: you have to manually specify all outputs in every rule
1: you have to manually specify all dependencies in every rule
0: no but, it just works.

I should figure out what I think the levels are, and write them down, perhaps starting from this list.

Add premake

thanks : )

Add digest example

Add example that relies on message digests, rather than file time modification.

No entry for Eyal Lotem's 'buildsome'

From a user's perspective, this is highly intriguing.

Auto clean test

To clean up only files you generated.

Command line flags need work

If you pass --continue it prints success in lots of places and doesn't fail with an exit code, it doesn't support --help etc. Need to rework the command line arguments, but retain the current flexibility. Ideally stick to "runhaskell just works", which restricts me to GetOpt.

Add order-only example

Following the Ninja order-only feature.

Turn on SCons in the Travis tests

Following #15, I should turn on SCons on the Travis machines so they are always checked.

Tup support

Hello, I'm working on adding tup to the shootout!

Tup prevents you from adding a target that overwrites an existing file. This is a wonderful feature, as it prevents you from accidentally blowing away your source code, etc... if you make a typo while writing and testing your build configuration.

If you change the tooling to not already have created the output files, you can pull my branch (drewm1980/build-shootout) and it ~may work. I'd issue a pull request, but as it stands, this issue breaks the build.

Cheers,
Andrew

unchanged: Handle files which do not change for GNU Make

I implemented qake specifically with such case in mind: it shouldn't regenerate files which are built from sources, for which the timestamp changed, but the source itself did not. So changing git branch doesn't incur full rebuild, as well as re-linking of the program is done only if the object files did truly change (which is not the case if you, for example, simply add a comment and build w/o debugging info).

I didn't generate Makefiles, although I do shell out (at least for hashing of the sources). So I wonder if this implementation counts. The implementation uses "higher-order macros" of GNU Make to generate all the proper rules. And it uses GNU Make for the build description and dependency tracking itself. Basically, it's a glorified mega-macro rule which generates full set of GNU Make rules with the property of "unchanged files don't cause changes that would propagate; only immediate output is rebuilt".

I can expand on the details and give a full test case if you think this qualifies as shootout entry. The Qake is more than just that, but the essential mechanism making it work might be applied to pretty much any build system, I think.