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

31–40 of 43 posts

Re: Non-Recursive Make Considered Harmful [pdf]

#31

Post by marssaxman »

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…

After loathing make for decades and doing my best never to waste any time thinking about it, I spent a week digging in hard and learning it in detail, as though it were a programming language I actually wanted to use. It turned out to be just as terrible as I always thought it was, and I really don't want to use it - but I learned how to make it do the straightforward thing I have always wanted it to do, which I have often fumed and sputtered and groused at it for not doing, and I wrapped that knowledge up in a set of recipes which I now copy into every project I work on. This lets me take advantage of make's ubiquity without having to remember and worry about all of its odd awful corners.

Here are the recipes, most recent version: https://github.com/marssaxman/ozette/blob/master/srctree.mk

And this is an example of a makefile using those recipes: https://github.com/marssaxman/ozette/blob/master/Makefile

Re: Non-Recursive Make Considered Harmful [pdf]

#32

Post by dietrichepp »

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…

Make is really fast, and it's good at doing parallel builds (you just have to specify -j). You could try making something better in Python, but it would take a long time to write and Make is already here. You apparently had the opposite experience from me. I hate NPM build systems like Grunt and Gulp because they're hard to debug. Make is easy—keep the files around and tweak the command line until it works.

No idea how you missed the -j option.

Re: Non-Recursive Make Considered Harmful [pdf]

#33

Post by technion »

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…

I was working on a CentOS 6 box not long back and it's shocking just how many big projects you pretty much can't build. Not because they didn't write portable C, but because they have requirements on a minimum version of autoconf, which is later than shipping under CentOS 6.

Re: Non-Recursive Make Considered Harmful [pdf]

#34

Post by veganman »

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…

Why are you even posting if you have zero knowledge of the topic?

Re: Non-Recursive Make Considered Harmful [pdf]

#35

Post by MichaelBurge »

Make is convenient for tiny programs, and annoying for larger ones. The system in GHC seems like a nightmare to maintain - I remember having trouble building GHC, mainly because it was hard to debug their system.

I use Docker for a similar purpose nowadays. It's inconvenient for development, since rebuilding the containers is slow. But it usually works without much trouble. I think there's a GHC Dockerfile somewhere that hvr maintains.

I haven't used Shake specifically much. The only thing that bugs me is that Haskell isn't nearly as portable as plain Make. If Shake didn't build the program but rather emitted a build-file that a small reference C program could interpret, I would feel much more comfortable about using it for just about everything. Because I'd know that if I was on some ancient CentOS 4 system, I could still build my software.

Re: Non-Recursive Make Considered Harmful [pdf]

#36

Post by tome »

rspeer wrote: post #28
tome wrote: post #13

Earlier quoted context omitted.

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!

Haskell libraries as well-maintained as Shake should not be hard to build on a fresh system (especially nowadays with Stack). Getting GHC onto a fresh system might be difficult if your package manager doesn't provide it.

Re: Non-Recursive Make Considered Harmful [pdf]

#37

Post by CJefferson »

cm3 wrote: post #24
CJefferson wrote: post #22

Earlier quoted context omitted.

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.

If you don't like auto-tracking dependencies, then tup certainly isn't for you.

For me, it is a killer feature -- any system where dependencies are maintained manually inevitably gets out of sync with the code. Some systems have special compiler hacks (like gcc's -MM flag), but you still have to find the magic option for each program you use, and link them into your compiler. That's also very hard to do in dynamic languages, where you don't know what libraries you have loaded until you've run the program.

Re: Non-Recursive Make Considered Harmful [pdf]

#38

Post by cm3 »

CJefferson wrote: post #37
cm3 wrote: post #24

Earlier quoted context omitted.

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.

If you don't like auto-tracking dependencies, then tup certainly isn't for you. For me, it is a killer feature -- any system where dependencies are maintained manually inevitably gets out of sync with the code. Some systems have special compiler hacks (like gcc's -MM flag), but you still have to find the magic option for each program you use, and link them into your compiler. That's also very hard to do in dynamic la…

> If you don't like auto-tracking dependencies, then tup certainly isn't for you.

I do use auto-generated/-detected deps for build time dependency graphs, but I didn't like how tup implements it.

Re: Non-Recursive Make Considered Harmful [pdf]

#39

Post by gnufx »

technion wrote: post #33
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…

I was working on a CentOS 6 box not long back and it's shocking just how many big projects you pretty much can't build. Not because they didn't write portable C, but because they have requirements on a minimum version of autoconf, which is later than shipping under CentOS 6.

autoconf _shouldn't_ be relevant to building, rather than maintaining the project. (I know you can't always get a proper release in this day and age.)

In some cases you do need to re-autoconfiscate, which is why EPEL6 has autoconf268 (from RHEL7). Otherwise there's a software collection with up-to-date autotools, though you might expect them in the devtoolsets.

Re: Non-Recursive Make Considered Harmful [pdf]

#40

Post by gnufx »

GFK_of_xmaspast wrote: post #21
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.

From considerable experience of building unixy packages, I wouldn't use "cmake" and "pretty good" together :-(.

Fedora EPEL6 has had to include two new cmake versions so far to be able to build more packages.

Post reply on HN