Non-Recursive Make Considered Harmful [pdf] • Hacker News Board

Re: Non-Recursive Make Considered Harmful [pdf]

#41

Post by tamana » Sun, Apr 10, 2016, 10:51 PM UTC

CJefferson wrote: post #3

Paper title is about yet another build system (this one written in Haskell), to replace Make. While make is awful, Most other build systems I've ever used have ended up being awful in their own way, and have the massive disadvantage that my users probably don't have the CMake 2.8.9.2 that I wrote my build script for. Also, I find it amusing that they claim Make's language is horrible, when they admit their replacemen…

The unicode arrow is just a pretty-printed ->

The bizarre opeators seem to be an attempt to maintain similarity to make's cryptic oerstorsr

Re: Non-Recursive Make Considered Harmful [pdf]

#42

Post by ndmitchell » Mon, Apr 11, 2016, 8:12 PM UTC

makecheck wrote: post #26

If your build reaches the point where you feel you need a wide variety of strange "make" constructs, you don’t necessarily need a new build system; you need to be smarter about the setup. For example: do everything in two phases , where the more “magical” version generates a less magical, verbose, static makefile with more rules that are relatively easy to understand and debug. And, besides: a huge impediment to impr…

The old GHC build system did do everything in 3 phases. And they were pretty magic phases. It's not clear there's any upper bound on the number of phases, and maintaining each phase separation is very tricky.

Re: Non-Recursive Make Considered Harmful [pdf]

#43

Post by ndmitchell » Mon, Apr 11, 2016, 8:14 PM UTC

amelius wrote: post #18

> To validate our claims, we have completely re-implemented GHC’s build system, for the fifth and final time. Until they re-implement it again :) > Unfortunately no cross-platform APIs are available to detect used dependencies, so such tools are all limited in which platforms they support. How about using libfuse? One could run the build inside a "virtual" folder served by libfuse, and thus detect all dependencies (t…

> Until they re-implement it again :)

As the paper says, every previous implementation started nicely and got horrible towards the end. This time, that hasn't happened, so _hopefully_ it's the final one. But, of course, never say never.

> How about using libfuse?

What about Windows? Certainly you could use something like libfuse, and we're trying other solutions - if we manage to build a cross-platform API Shake will be able to use it easily.