Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Non-Recursive Make Considered Harmful [pdf]

research.microsoft.com

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Non-Recursive Make Considered Harmful [pdf]

#21

Post by GFK_of_xmaspast »

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…

> my users probably don't have the CMake 2.8.9.2 that I wrote my build script for

cmake is "pretty good" about exposing policy flags to control compatibility.

Re: Non-Recursive Make Considered Harmful [pdf]

#22

Post by CJefferson »

cm3 wrote: post #6
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…

I suggest to read more about Shake before dismissing it. The paper is short and easy to follow. Shake solves real world problems that go ignored in other systems. If needed, one could add a simple mode via an EDSL, but so far nobody using Shake has requested such a things from what I can tell, but Neil would be better equipped to answer that. I haven't written a single Shakefile with unicode, and no you don't have to…

I did read all of that. To me, the system seems inferior to tup, which they discuss (tup doesn't require me to specify dependencies, which I consider a killer feature). Also, tup works on windows, while that paper suggests Shake doesn't.

Re: Non-Recursive Make Considered Harmful [pdf]

#23

Post by _0w8t »

dietrichepp wrote: post #9
wrong_variable wrote: post #2

I knew Make was terrible when I was first introduced to it. This is why I think everyone should learn programming first and linux second - since many linux tools are terrible. As expressed in the SICP book - the programming language should allow you to build abstractions. Make doesn't at all allow that.

I think you were misinformed about the purpose of Make. It should not be used as a programming language. You can write a short makefile by hand, reasonably, which compiles a few source files, but anything larger should probably be automatically generated by CMake or your own scripts or whatever. Abstractions are perfectly possible, you just do it in your own script (Python or whatever) and this way you don't have to…

Nice summary! It is indeed often missed but rathar important point that make syntax is generator-friendly. It allows to easily script make files or even glue them together from several generators.

This ability to write and compose is a rare feature today. Json is pretty opposite to it and even Yaml is rather bad at it as to compose pieces one have to parse them first.

Re: Non-Recursive Make Considered Harmful [pdf]

#24

Post by cm3 »

CJefferson wrote: post #22
cm3 wrote: post #6

Earlier quoted context omitted.

I suggest to read more about Shake before dismissing it. The paper is short and easy to follow. Shake solves real world problems that go ignored in other systems. If needed, one could add a simple mode via an EDSL, but so far nobody using Shake has requested such a things from what I can tell, but Neil would be better equipped to answer that. I haven't written a single Shakefile with unicode, and no you don't have to…

I did read all of that. To me, the system seems inferior to tup, which they discuss (tup doesn't require me to specify dependencies, which I consider a killer feature). Also, tup works on windows, while that paper suggests Shake doesn't.

I didn't try tup, but I found the way it's said to detect dependencies by monitoring stuff to be a bad idea, though this is probably my personal preference. Can't tell how many developers don't like that design aspect.

Shake should work on Windows, given that Neil wrote a Windows progress bar tool for Shake.

Re: Non-Recursive Make Considered Harmful [pdf]

#25

Post by cm3 »

dietrichepp wrote: post #16

Reading the article, I wonder if Shake could be used to generate Ninja files. It looks like it might be possible. The main "backend" improvements in Shake are things like concurrency reduction (pools in Ninja), hash-based rebuilding (available but undocumented in Ninja), and generated dependency rules. In such a setup, you'd use Shake for all your abstractions, and Ninja to execute the rules.

Shake can interpret Ninja files, actually.

But I can see the appeal of Ninja files of something that allows one to avoid the GHC requirement in a build environment.

Though I've found Ninja to be more like something that needs to be generated from something else and less something you'd write. So maybe Ninja can be exactly that, kinda like build script assembly.

Re: Non-Recursive Make Considered Harmful [pdf]

#26

Post by makecheck »

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 improving the state of build systems is that new build mechanisms won’t be installed on most platforms by default. If you must explore new ways to build, be sure to implement that in terms of what is already there (Perl/Python/whatever) and make sure to ship your new build system WITH your code.

When I download some "neat-project-1.0.tar.gz", the last thing I want is to have to futz with setting up your special build system that Probably Nothing Else uses or will ever use. If it’s not in the tarball, I will already lose a lot of interest; I know most things can "configure, make, make install" in minutes but I don’t know how much time will be wasted installing whizbang-build-0.1 first and I probably won’t even try.

Re: Non-Recursive Make Considered Harmful [pdf]

#27

Post by cm3 »

dietrichepp wrote: post #9
wrong_variable wrote: post #2

I knew Make was terrible when I was first introduced to it. This is why I think everyone should learn programming first and linux second - since many linux tools are terrible. As expressed in the SICP book - the programming language should allow you to build abstractions. Make doesn't at all allow that.

I think you were misinformed about the purpose of Make. It should not be used as a programming language. You can write a short makefile by hand, reasonably, which compiles a few source files, but anything larger should probably be automatically generated by CMake or your own scripts or whatever. Abstractions are perfectly possible, you just do it in your own script (Python or whatever) and this way you don't have to…

The problem with generated Makefiles is that you start to debug the generation step, if possible, if you want to tweak things, whereas a Makefile written by a human is usually easy to edit. Alternatively the generated Makefile could use overrides from an optional .mk file to be sourced, but that's not what I've seen with automake or cmake.

Re: Non-Recursive Make Considered Harmful [pdf]

#28

Post by rspeer »

tome wrote: post #13
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…

It's not just written in Haskell, it is Haskell. Your "Shakefile" is a Haskell source file. You understand the syntax if you understand Haskell syntax, and vice versa. And no, you don't have to write Unicode arrows. You write those things as ->. For some reason academic Haskell papers use Unicode symbols where real Haskell uses ASCII.

Build systems are a good case for a domain-specific language that just knows about how to build things. Make may not always be the right DSL.

"Here's a Haskell library, go write your own build system in Haskell" is technically a solution to every build problem, but not a very practical one. Especially because Haskell libraries are themselves so hard to build on a fresh system!

Re: Non-Recursive Make Considered Harmful [pdf]

#30

Post by pmoriarty »

wrong_variable wrote: post #20
dietrichepp wrote: post #17

Earlier quoted context omitted.

CMake can't generate anything, it only generates a few different types of files. Make is the most well-tested output, and there is only one alternative generator for CMake for the Linux command line anyway (Ninja, which is even less expressive than Make). It's like saying that "Why use assembly at all? GCC could generate anything." Well, yes. But you're on an x86 machine and there's an assembler right there for GCC t…

All of these things sound complicated. What is CMake now ? Manipulating files is trivial in any programming language expect maybe in something like C,C++,Java,etc. Python/js/go make it really easy to deal with complex build systems or even just 1 liners. So I have no idea why make has any advantage over those - only use-case is if you are writing C where its non-trival to do file-handling. I moved to npm scripts once…

"I moved to npm scripts once I asked the question 'how do i make a multi-process build script in make ?' and all the neck-beards in uni had no answer"

  make --jobs=2
Post reply on HN