Titles containing considered harmful considered harmful
Comments containing "considered harmful considered harmful" considered besides the point.
Non-Recursive Make Considered Harmful [pdf]
11–20 of 43 posts
Re: Non-Recursive Make Considered Harmful [pdf]
#12Titles containing considered harmful considered harmful
I assume they are playing off the 1997 article "recursive make considered harmful"
Re: Non-Recursive Make Considered Harmful [pdf]
#13Paper 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.
Re: Non-Recursive Make Considered Harmful [pdf]
#14Titles containing considered harmful considered harmful
Everybody wants to be Dijkstra.
Re: Non-Recursive Make Considered Harmful [pdf]
#15I 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…
In which case why even use Make at all? CMake could generate anything.
Re: Non-Recursive Make Considered Harmful [pdf]
#16Reading 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.
Re: Non-Recursive Make Considered Harmful [pdf]
#17Earlier quoted context omitted.
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…
In which case why even use Make at all? CMake could generate anything .
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 to use, and GCC has been using that assembler for decades.
Re: Non-Recursive Make Considered Harmful [pdf]
#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 (they will show up as "read" operations in the libfuse API).
Re: Non-Recursive Make Considered Harmful [pdf]
#19Paper 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…
Build systems and functional programming languages are a good match, because of the way dependencies work. Therefore, I give this tool a good chance of being succesful (though I'm not sure if/how they will win over the non-Haskell crowds). At a first glance, this paper seems very interesting. This is certainly not "yet another" build system.
Re: Non-Recursive Make Considered Harmful [pdf]
#20Earlier quoted context omitted.
In which case why even use Make at all? CMake could generate anything .
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 asked the question "how do i make a multi-process build script in make ?"
and all the neck-beards in uni had no answer - so I just write small scripts which grow and shrink based on my needs.