Live data from Hacker News

Make for hipsters

mattandre.ws

21–30 of 200 posts

Re: Make for hipsters

#21

> You need to create a makefile to tell make what to do. Nope. You can say "make hello" and have make automatically use its default rules - which can be configured - to e.g. compile hello.c into a hello executable. I use this frequently.

Make's default implicit rule set is very useful for C, C++, Fortran, Pascal, and basically nothing else.

Out of curiousity: how do you configure the implicit ruleset? I wasn't able to find documentation on that (the closest I found was https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter..., which explicitly documents the Make implicit rules but says nothing about changing/augmenting them).

Re: Make for hipsters

#22
post #16

Earlier quoted context omitted.

I suppose so. But there are always many tools for everything. And everyone can select his favorite.

The problem is if you want support (even commercial help) you'll need to follow some kind of prevailing trend. If I've got a system with grunt or gulp and I need help, I can probably find a local web developer. I'm not so sure if I can find someone who's an expert in Makefiles at the moment.

You already found at least one. Also try anyone with a degree in computer science. I'd wager it's in most first year courses; it was in 3 of mine. Also you could consult anyone who spends a lot of time working on/programming for Linux and/or in C/C++.

And it's really easy, and there's tons of literature on it on the internet. And it has a manpage.

Re: Make for hipsters

#23

Make is a great tool for automating simple things, but if you use a programming language you should probably use native automation tools for common tasks. If you have any non-trivial logic or want to enable code-reuse make doesn't seem like the right choice either.

I hate this. Every programming language that bolts on its own build environment. Make is language agnostic and that's a huge benefit, it means you have to learn about just one build tool and its peculiarities and that will allow you to build many different projects in different languages.

All these languages with their half-baked build tools that won't accept that they may have to play nice with other languages and their build tools are not helping.

Of course it is great when you write a language to also throw in a build tool, but in the end if the build tool re-implements 30% or so of make in a broken way I don't see the point.

Make does have its limitations, but most ordinary projects get nowhere close to reaching those.

Re: Make for hipsters

#24
The single biggest piece of advice I can give for Make is to make sure your text editor uses real tabs in Makefiles. My personal preference for everything is spaces (mostly a habit learned from Python's PEP 8), but Make doesn't honour spaces for indentation - only tabs.

Despite being an obvious usability hole, this has never been fixed. Exacerbating the issue is the poor error message given upon encountering a space-indented line in Make:

    Makefile:2: *** missing separator.  Stop.
Make is ubiquitous and fairly easy to use, but it's warts like this that remind you that it is fundamentally a build system from the far past.

Re: Make for hipsters

#25
post #10

Do so many people who go on this site not know how to make makefiles? Also why is it for hipsters? Or is the article for hipsters? Why does the author call his own published notes factually inaccurate? Why is it hacky to use a makefile? Is this all a big ruse?

(1) I imagine quite a lot of this site's visitors use different platforms/toolchains, and haven't encountered make. (2) Its a fun/joke title, the article is for "hipsters", the kind who know the latest fancy build tools but not make, I suppose. I wouldn't take it too seriously. (3) It's a disclaimer against people attacking him for errors, and also to warn people that he's not an expert. Again, this is written in a lighthearted way. (4) See 3. (5) Maybe, or maybe you are just feeling cranky today.

Re: Make for hipsters

#26

> You need to create a makefile to tell make what to do. Nope. You can say "make hello" and have make automatically use its default rules - which can be configured - to e.g. compile hello.c into a hello executable. I use this frequently.

Make's default implicit rule set is very useful for C, C++, Fortran, Pascal, and basically nothing else. Out of curiousity: how do you configure the implicit ruleset? I wasn't able to find documentation on that (the closest I found was https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter... , which explicitly documents the Make implicit rules but says nothing about changing/augmenting them).

Many implicit rules make use of variables, which you can change as you see fit. For example, creating an object file from a C file will do something like "$(CC) $(CFLAGS) $Other than that there's not much configuration, but the predefined rules are usually quite simple, so it's pretty easy to just write your own implicit rules if the predefined ones don't suit your needs.

Re: Make for hipsters

#27

Make is a great tool for automating simple things, but if you use a programming language you should probably use native automation tools for common tasks. If you have any non-trivial logic or want to enable code-reuse make doesn't seem like the right choice either.

That's true, but it also leads to bloated special purpose tools that take minutes to run, as described in the introduction of the article.

Sometimes you've better off having something that does exactly what you need, regardless of speed. Sometimes you need something fast, lightweight, ubiquitous, and reliable despite its quirks.

Re: Make for hipsters

#28
I routinely use a Makefile for building my frontend resources, which works quite well:

https://github.com/adewes/gitboard/blob/master/Makefile

Using the inotify tools it's even possible to automatically trigger a rebuild whenever a file changes.

For me, no need to use Gulp anymore, as Makefiles are easier to reason about, more composable and make use of existing infrastructure instead of reinventing the wheel over and over again.

Re: Make for hipsters

#29

Make is a great tool for automating simple things, but if you use a programming language you should probably use native automation tools for common tasks. If you have any non-trivial logic or want to enable code-reuse make doesn't seem like the right choice either.

I hate this. Every programming language that bolts on its own build environment. Make is language agnostic and that's a huge benefit, it means you have to learn about just one build tool and its peculiarities and that will allow you to build many different projects in different languages. All these languages with their half-baked build tools that won't accept that they may have to play nice with other languages and t…

> Make is language agnostic and that's a huge benefit, it means you have to learn about just one build tool and its peculiarities and that will allow you to build many different projects in different languages.

You need to learn the Make build tool (easy) and then you need to learn bash scripting to get anywhere (argh!).

The OP has linked an example Makefile and I wouldn't be able to maintain/debug it without reading plenty of manpages:

https://github.com/Financial-Times/n-makefile/blob/master/Ma...

Re: Make for hipsters

#30
post #8

This introduction neglects to mention that Makefile rules are primarily rules to derive files (usually from other files). Make will not re-run a rule when the target (file) generated by the rule is already up to date. From this perspective, a well structured Makefile can be thought of as a pipeline/graph of functions, that derive values (files) from previously known values (files). Expressing a build process in this…

For anyone who's curious: you can use a ".PHONY" target to force targets to be rebuilt (i.e. that they don't correspond to real files). All dependencies of the .PHONY pseudo-target will be rebuilt unconditionally when encountered. Typically, "all", "clean", "install", etc. will all be phony targets as the goal isn't to literally make a file called "all". The syntax is simple: .PHONY: all clean install marks "all", "c…

> All dependencies of the .PHONY pseudo-target will be rebuilt unconditionally when encountered.

To be clear, they will rebuilt only if they are not already up to date relative to their own dependencies, right?

Post reply on HN