Time for Makefiles to Make a Comeback

Post by akvadrako » Tue, Sep 05, 2017, 8:04 PM UTC

Yaggo wrote: post #66

akvadrako wrote: post #5

Earlier quoted context omitted.

The data model of makefiles is perfect for watching and rebuilding. All you need to add is something that monitors the source files for any changes and runs 'make'.

You lose incremental builds of modern bundlers/transpilers, which makes your build time too slow for bigger projects. People nowadays expect to see changes almost in realtime using hot module replacement etc.

Post by abritinthebay » Tue, Sep 05, 2017, 8:27 PM UTC

stephenr wrote: post #92

abritinthebay wrote: post #73

Earlier quoted context omitted.

Eh, different strokes. Every time I have to use Makefiles I yearn for the comparative flexibility and simplicity of the JS ecosystem. Make files just seem good to users of the due to experience. They work, but let’s not pretend they’re easy to work with.

> simplicity of the JS ecosystem [citation needed]

Post by Walf » Tue, Sep 05, 2017, 9:40 PM UTC

humanrebar wrote: post #69

bsenftner wrote: post #27

I've been using make files constantly since '76 when I first started programming in (US) 5th grade. It has been one of my career amusements watching the build systems come and go. I gave up talking about Make years ago. There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. I use one of the earliest Make versions that barely does…

> There is a huge population of us that smile and get things done, while others screw around with new, complicated, never-learned-the-past tools. They get the things done they've been doing all along. But build metadata is very important and very hard to extract from Makefiles, especially as builds increase in complexity. You need things like search paths accessible to get IDEs, static analyzers, software packaging s…

Post by lederhosen » Tue, Sep 05, 2017, 10:03 PM UTC

llimllib wrote: post #72

jgrahamc wrote: post #62

I have a theory that the people who love make are the same people who love macros and the people who hate make don't love them. I wrote a book on make and I fully recognize that there are people who look at what I've written there and think I'm completely mad: https://www.nostarch.com/gnumake Make's greatest irony is that it's a system for building files based on dependencies but has no way of actually discovering de…

(disclaimer: I like make but not macros) > And make has deficiencies that are a nightmare to work around and get right (e.g. spaces in filenames, recursion, ...) Yes! we seem to be stuck in a local maximum with make. I wrote my own make replacement, as have many before me, and learned the folly of my own ways. Nowadays I use (and love) make despite its terrible handicaps, but I really wish there were something fundam…

Post by Asooka » Tue, Sep 05, 2017, 10:55 PM UTC

humanrebar wrote: post #96

Walf wrote: post #95

Earlier quoted context omitted.

I don't understand your reasoning here. Make can call any program, and contain as many build targets as you would ever need. If some task can't be accomplished in Make itself or existing CLI programs, you write something that does that one task well, then ensure Make runs it whenever needed, even if that's every build.

You could write make rules to do about anything, sure. But you don't want to have to rewrite those rules for every project. You want make modules that you can reuse from project to project. Those are notoriously hard to get right. And when they are done correctly, they are hard to share across organizations, or even within large organizations. In particular, I write a lot of C++. I want targets for gcov, g++, gtest,…