Re:Build Tools – Make, no more
by gradstudent on Tuesday April 22, 2014 @12:55AM
(#7625890)
Perhaps I'm just jaded but what you describe sounds a lot more complicated for most people than just writing a Makefile. Perhaps even the vast majority of people. I think you underestimate how far you can go with just a vanilla make build system.
Can you show an example of what you are describing? It doesn't sound interesting for the tasks I have in mind, so it must be the case that you are dealing with very complex tasks.
See ASDF, for example (http://common-lisp.net/project/asdf/).
Your build system has types? Is that so you can catch errors at compile time instead of run time? Who builds the build tool?
I know you're just being glib, but here are some answers:
* build doesn't mean compile
* you can compile your build process and then use that to actually run your build
* the benefits of typed languages go beyond catching errors at compile time
There are tools like ocamlbuild and cabal, which are implemented in Ocaml and Haskell, and used to build Ocaml and Haskell.
But ocamlbuild doesn't have a build file. It just knows how to build Ocaml. And build Ocaml is about all it can do. Cabal is powered by a .cabal file, which is a data structure, and a Setup.hs file, which is run like a shell script via runhaskell.
I think what tikhonj envisions would be a lot of work to achieve. Maybe he already knows that. I suspect that the closest most of us will ever get is putting something like this at the top of a Makefile :)
.ONESHELL:
SHELL = /usr/bin/runhaskellIf you want to use Make, read "Recursive Make Considered Harmful" first (http://aegis.sourceforge.net/auug97.pdf).
Your build system is an integral part of your whole program and you want to treat it just like any other code. This means refactoring, this means modularity, this means libraries, this means no copying and pasting... All this is far easier with a system embedded in your main language than in Make. You can use your existing tooling, debuggers and frameworks to support your build system. If you're using a typed language, you can use the types to both constrain and guide your build files, making everything safer.
Using an embedded DSL integrates far better with the rest of your ecosystem than relying on Make.
Apart from making the logic of your build system easier to describe and maintain, an embedded DSL also makes arbitrary meta-tasks easier. You might want to monitor random parts of your build process, report to different services, connect to different front-ends (an IRC bot, a CI system...) and maybe even intelligently plug into the features of your main language. Wouldn't it be great to have a make system that's deeply aware of how your server is configured, how your type system works, what your compile-time metaprogramming is doing an so on?
You could just glue together a bunch of disparate scripts with a Make file. Or you could use a DSL and call these services through well-defined, maybe even typed interfaces! No need for serializing and deserializing: you can keep everything inside your system.
Sure, if you're just going to use your DSL as a different syntax for Make, you're not gaining much. But it allows you to do far more in a far better way, while fitting in more naturally with the rest of your code. I'm definitely all for it!