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

Time for Makefiles to Make a Comeback

medium.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Time for Makefiles to Make a Comeback

#101

Post by humanrebar »

Asooka wrote: post #99
humanrebar wrote: post #96

Earlier quoted context omitted.

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,…

I also write C++ and am not aware how to comfortably automate all that with a single build tool. Is it some sort of cmake extensions? Can you please share your setup?

Some of those are built-in to cmake you can google "cmake clang-tidy" to find some examples, for instance. The rest can be added as custom targets and/or custom configuration options.

The point is that you can write reusable cmake modules you can ship with your package manager or even git and a tweaked cmake search path. You can get there with make, but it's more work and a bit of a pain to replicate and maintain. In fact I often see teams with those setups put too many things in their repos to avoid build tool pain. Or, perhaps more often, they just give up on ever getting clang builds to work (for instance).

Re: Time for Makefiles to Make a Comeback

#102

Post by pippy »

overgard wrote: post #58

Nonononono. There's a reason makefiles have been reinvented 400 times: they're a nightmare. I don't love the alternatives, but they are pretty much all universally better.

Dependency hell is one of the main reasons why developers are flocking to bloated solutions such as election: a single monolithic dependency with guaranteed cross functionalist behavior.

Most build tools are stuck in the 70-80's where a single library weighing hundreds of kilobytes was a big thing. In comparison to saving a few kilobytes vs spending hours of a developers time hunting down old versions of libraries is a no-brainier. Especially when you take security into account. I've seen .Net developers just give up in frustration and download dll files from those dodgy download sites and put them into production distributions.

I personally loathe make. I've never had a good experience when using it.

Re: Time for Makefiles to Make a Comeback

#103

Post by stephenr »

abritinthebay wrote: post #93
stephenr wrote: post #92

Earlier quoted context omitted.

> simplicity of the JS ecosystem [citation needed]

Citation: I work with it every day. You can make it complex but that’s true of everything. It’s not hard or complex to get working initially, or maintain, which is not true of makefiles

> It’s not hard or complex to get working initially, or maintain, which is not true of makefiles

Again, [citation needed].

I use Makefiles in a variety of projects:

- building Vagrant base boxes

- building environment-specific configuration for LAMP-ish CRUD apps

- testing and building a range of shell-script based packages

Does Make have some warts? Sure, everything does. I'm not claiming it's perfect.

But it's a far sight clearer - to me at least - what's going on with a Makefile.

Makefiles also don't need to be replaced by something new in 6 months because the entire community has decided that its time for a new tool to do basically the same thing, solve 1 problem with the old tool and introduce 5 new ones.

Re: Time for Makefiles to Make a Comeback

#104

Post by zimpenfish »

sounds wrote: post #100
zimpenfish wrote: post #44

Earlier quoted context omitted.

+1 for do/redo. Although it can be a bugger to get right for go (because there's no intermediate files) (although I think I've solved that now.)

I looked at your profile, but didn't see any clues. Please share? How do you use redo for go projects?

[looks at pending blog posts guiltily]

https://bitbucket.org/rjp/can-x-win/src is a good example - basically, apart from `all.do` containing the targets, I have a `default.do` which looks for a matching `*.od` which has the DEPS and then passes those to `go build`.

Re: Time for Makefiles to Make a Comeback

#105

Post by Yaggo »

akvadrako wrote: post #91
Yaggo wrote: post #66

Earlier quoted context omitted.

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.

That's because those tools aren't designed to play well with others. It's not due to the design of make.

I would say it's partly because of the design of make.

A Makefile consists of separate commands¹ and is heavily file-based¹, which makes it rather slow and doesn't allow to keep state (in memory) between re-runs. Traditionally this hasn't been bottleneck, because compiling C code was relatively slow operation, but modern web development tools prefer to work with in-memory streams instead of invoking executables for tiny files on disk.

I'm not saying you cannot do things with make, but in NodeJS/web ecosystem it just doesn't feel as natural/flexible as the "native" NodeJS-based toolchain.

[1] Great for interoperability, but sometimes more tailored solution is worth it.

Re: Time for Makefiles to Make a Comeback

#106

Post by JdeBP »

Iv wrote: post #86
mikegerwitz wrote: post #40

Earlier quoted context omitted.

Make isn't intended to be used for dependency management. With traditional `./configure && make && make install`, dependencies are detected by the configure script, or manually provided by the user if they have custom library paths. Dependencies are handled by your package manager or something else (be it submodules in git, custom scripts, etc). There's a separation of concerns. For generating those configure files,…

Well ./configure does not install dependencies either. Even worse: it fails at the first missing dependency instead of listing them. Making an automake project to compile is actually a long and manual process. Just today I had to compile an older version of gimp, just a 2 years old one. Configure. Fails. Apt-get this. Configure. Fails. Apt-get that. Oh, no, configure doesn't want obscure-package4, it wants obscure-pa…

Why wasn't

    apt-get build-dep gimp
or

    aptitude build-depends gimp
the easy answer?

Re: Time for Makefiles to Make a Comeback

#107

Post by JdeBP »

jph wrote: post #16

For a better "make" try "do" (also known as "DJB redo"). It's designed by Dan Bernstein of crypto fame and implemented by Avery Pennarun now at Google. http://apenwarr.ca/log/?m=201012#14 I will contribute $100 to any Rust leader who wants to start coding "do" in Rust.

That's somewhat misleading.

* http://jdebp.eu./FGA/introduction-to-redo.html

* https://news.ycombinator.com/item?id=15060193

Re: Time for Makefiles to Make a Comeback

#108

Post by JdeBP »

orclev wrote: post #38
Iv wrote: post #34

If you compare Makefiles to the JavaScript ecosystem it will do so favorably, but many things will. Make is a good build system but it is a shitty deployment system. Yes, you can do everything you want if you put enough effort in it as it is a complete scripting system, something many alternatives are not. It does not mean that it is a good idea to do so. Recently a client made me begrudgingly try Maven. 'Yet another…

That last bit is really key. Nearly every modern build system is also a dependency management system, something that really isn't possible using Make. There have been tools introduced to address that particular need for C/C++, but they integrate poorly if at all with the build system, so it turns all your builds into (at least initially) three step processes of run dependency installer, run config tool to figure out…

redo is mentioned elsewhere in this very discussion.

One of the things that Daniel J. Bernstein did in his packages is merge steps two and three. There would be makefile/redo rules for detecting the presence of operating-system-specific stuff, and linking the appropriate source/header files into place.

Here's an example from ucspi-tcp that auto-configures whether the platform supports waitpid():

* https://github.com/comotion/ucspi-tcp/blob/master/Makefile#L...

* https://github.com/comotion/ucspi-tcp/blob/master/choose.sh

* https://github.com/comotion/ucspi-tcp/blob/master/trywaitp.c

* https://github.com/comotion/ucspi-tcp/blob/master/haswaitp.h...

* https://github.com/comotion/ucspi-tcp/blob/master/haswaitp.h...

When I extended redo to the whole of djbwares, this system was fairly simple to convert. Here is haswaitp.h.do which is what redo ends up running whenever something reveals a dependency from haswaitp.h :

    #!/bin/sh -e
    redo-ifchange trywaitp.c compile link
    if ( ./compile trywaitp.o trywaitp.c trywaitp.d && ./link trywaitp trywaitp.o ) >/dev/null 2>&1
    then
            echo \#define HASWAITPID 1 > "$3"
    else
            echo '/* sysdep: -waitpid */' > "$3"
    fi
* http://jdebp.eu./Softwares/djbwares/

Re: Time for Makefiles to Make a Comeback

#109

Post by akvadrako »

Yaggo wrote: post #105
akvadrako wrote: post #91

Earlier quoted context omitted.

That's because those tools aren't designed to play well with others. It's not due to the design of make.

I would say it's partly because of the design of make. A Makefile consists of separate commands¹ and is heavily file-based¹, which makes it rather slow and doesn't allow to keep state (in memory) between re-runs. Traditionally this hasn't been bottleneck, because compiling C code was relatively slow operation, but modern web development tools prefer to work with in-memory streams instead of invoking executables for t…

Launching a process on Linux only takes about 2ms, and make only needs to do it for parts that change. There is no reason you couldn't use a make-based system to get incremental rebuilds with under 100ms latency, which is about as good as most people get with native JS systems.

Re: Time for Makefiles to Make a Comeback

#110

Post by Walf »

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,…

Make's ability to include other makefiles is insufficient? Surely there's a relatively simple structure that would let you modularise tasks then include only the relevant ones per project.
Post reply on HN