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

Using Make – writing less Makefile

text.causal.agency

Post reply on HN
Print view View original

121–130 of 200 posts

Re: Using Make – writing less Makefile

#121

Post by enriquto »

bxparks wrote: post #53
rochak wrote: post #47

Gonna get downvoted to oblivion for saying this but I haven't hated a tool more than make.

Not downvoting you. Just curious to know why? In my experience, as long as the Makefile is less than about 100 lines, it's the most useful workflow system ever. Because it's available almost everywhere. After about 100 lines, yeah, it is not great. And that idiotic tab character. I know the historical reason why tab was used. I wish they had fixed it to accept both tabs and spaces a long time ago.

> I wish they had fixed it to accept both tabs and spaces a long time ago.

I have good news for you: this is already the case! In all modern versions of make you can use semicolons instead of tabs.

You just write

    target : dependencies ; rule
instead of

    target : dependencies
    ^Irule
if, for some reason, you hate the beautiful tab characters.

Re: Using Make – writing less Makefile

#122

Post by t43562 »

nickelpro wrote: post #117
t43562 wrote: post #103

Earlier quoted context omitted.

Make has few dependencies so it's a way to build an operating system up from ground 0. Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. So it gets used a lot and it's only a language for dependencies and rules. It doesn't do "project management". Its the simplicity of what it's trying to that saves it from…

> Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. This is a non-priority, an unreal use case. I can't build GCC without a functioning C++ compiler and a fairly sophisticated OS environment and that's fine. Real-world use cases for bootstrapping a build environment from rubbing two sticks together are so ex…

Make exists and is used widely and not because everyone's too inept to understand your points.

The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. The more they assume the more niche they become.

Re: Using Make – writing less Makefile

#123

Post by pests »

082349872349872 wrote: post #120
pests wrote: post #44

Earlier quoted context omitted.

I have vision problems, I increase zoom a lot in desktop and mobile. What do you have against people different than youself?

Nothing; I wished you luck! I imagine people with screenreaders have an even tougher time... (mobile I agree would be hopeless with zoom [I avoid reading on mine even without zoom], but does your desktop zoom mean even TFA's vt100-friendly 72-chars needed reflowing?)

I don't always increase zoom but TFA is def too small on desktop. I just increase until its readable, that being said, the article is comfortable for me at about 200-250%. Reflow issues seem to occur at 300% - so no issue for me but I could see some people going that high.

Re: Using Make – writing less Makefile

#124

Post by [deleted] »

nine_k wrote: post #91
hathawsh wrote: post #86

Earlier quoted context omitted.

With all due respect, I don't understand the first part of your comment. Make's core purpose is to execute commands, isn't it? How was it not designed to execute commands?

No, no. Make's principal purpose is to put a set of files into a desired state. It can "make" a particular file by invoking a dependent graph of commands that produce that file from other files. It checks timestamps and only run steps where the resulting files are older than some of the (transitive) source files. You can invoke it by naming a named rule, not a file, but the logic will remain. If this is not what you…

[deleted]

Re: Using Make – writing less Makefile

#125

Post by matheusmoreira »

01100011 wrote: post #62

Nice to see some love for make. Sure, make syntax sucks. It's arcane and hard to google much of what is going on. (Shower thought... a tool that lets you view a Makefile, giving explanatory tooltips for syntax elements would be great). But make is widespread, ancient and eternal. It isn't going anywhere, despite decades of new tools trying to take its place. It does many jobs relatively well. I'd go so far as to say…

> But make is widespread, ancient and eternal.

Yeah. The GNU Make is literally everywhere, it's too useful and it's got too many good features. GNU Make is worth learning and using just because of this. Having to deal with non-make systems is seriously annoying.

> It does many jobs relatively well.

I wonder if anyone else other than me was insane enough to try and use GNU Make to manage dotfiles? I even blogged about it.

https://www.matheusmoreira.com/articles/managing-dotfiles-wi...

Gotta be really careful with stuff like that. GNU Make is simultaneously a rather lisplike metaprogrammable language and a turing tarpit. I screwed up a personal project once because I got sidetracked essentially reinventing a fraction of autoconf in pure GNU Make code.

Now I try to keep things as simple as possible. I still understand the makefile so I suppose it's simple enough.

Re: Using Make – writing less Makefile

#126

Post by wokwokwok »

bxparks wrote: post #53
rochak wrote: post #47

Gonna get downvoted to oblivion for saying this but I haven't hated a tool more than make.

Not downvoting you. Just curious to know why? In my experience, as long as the Makefile is less than about 100 lines, it's the most useful workflow system ever. Because it's available almost everywhere. After about 100 lines, yeah, it is not great. And that idiotic tab character. I know the historical reason why tab was used. I wish they had fixed it to accept both tabs and spaces a long time ago.

You see, this is why I personally hate make: automake.

As you say, a small elegant makefile is lovey.

That is not the sort of makefile you get from the autoconf/automake family, and (ha!), good luck if something goes wrong.

The reality is that a small simple makefile is not sufficient to build real software.

The problem is fundamentally that make doesn’t compose well.

Most real build systems such as cmake, scons, cargo, etc. provide primitives for dealing with complex messy situations like “oh today I’m using visual studio not clang” or “does this platform have stdbool.h?” or “is the flag for disabling a warning different on this compiler?”

…and a way of composing that tasks into smaller ones (eg. add_subdirectory() and find_package()).

Make does not.

Make is a simple tool for simple tasks.

The reason people don’t like it, in my experience, is they have had to work with a make based project that has grown beyond the trivial size and it’s become a nightmare.

It makes easy things easier, and hard things much harder.

If worked on SPAs where they used make instead of webpack; but it’s a stupid solution. It doesn’t do live reloading, or any of the other pipeline stuff… but by gosh they tried!

You know what I like about clojure? It’s a simple tool that scales well for both simple and complex tasks.

Make simply doesnt.

…and that is reflected in the reality, which is that increasingly build tools are moving away from it and towards others, even for the low level tasks that people used to “generate makefiles” for eg. to ninja

I really am not a cmake fan; but there absolutely no denying it works very well in many real world situations, where trivial “-lsqlite” flags in a naive makefile don’t and cant work.

Re: Using Make – writing less Makefile

#127

Post by maleldil »

KajMagnus wrote: post #104
nine_k wrote: post #91

Earlier quoted context omitted.

No, no. Make's principal purpose is to put a set of files into a desired state. It can "make" a particular file by invoking a dependent graph of commands that produce that file from other files. It checks timestamps and only run steps where the resulting files are older than some of the (transitive) source files. You can invoke it by naming a named rule, not a file, but the logic will remain. If this is not what you…

I also don't like Make for running commands. I was using Make for running commands, but it interprets all command line parameters as build targets, which was annoying. And Bash scripts in Makefiles aren't type safe, became messy. Nowadays I use Make only for building. And Deno + Typescript instead, for running commands & scripts. (Hadn't heard about Just — the scrips aren't type safe though?)

> Hadn't heard about Just — the scrips aren't type safe though?

Just runs code written in other languages. It's `sh` by default, but you can define anything (e.g. `python3 -c` to run Python scripts).

Re: Using Make – writing less Makefile

#128

Post by spc476 »

Tyr42 wrote: post #92

I honestly wish that make's default rules were available to import and view the source of, but we're disabled by default. Then a beginner could see what happens in a straightforward way, and then import the C rules. And we could all stop importing the VCS rules which aren't useful anymore.

I don't know about POSIX make, but GNU make you can run "make -p -f/dev/null" to get a dump of all the built in rules it has. And if you don't want to run those, you can always use "make -r" to have it ignore built in rules.

Re: Using Make – writing less Makefile

#129

Post by dextercd »

I wish people actually defined the dependencies between .c and .h files and .h and other .h files. When a project doesn't do this, I always and up doing a `make clean && make` after getting stuck on a weird bug because I just assume it's not rebuilding something it should.

Nowadays I use CMake and am really happy with it.

Re: Using Make – writing less Makefile

#130

Post by matheusmoreira »

adrian_b wrote: post #35
Karellen wrote: post #24

Earlier quoted context omitted.

But the OBJS allows for an easy `clean` target, defined further down the article. Personally, I'd have gone with foo: $(OBJS) $(CC) $(LDFLAGS) -o $@ $ to put all flag options first, then the output option, then using `$ But that is somewhat idiosyncratic, and based on some half-remembered ideas of second-hand stories of how compilers used to process their command parameters back in the '90s (and before). Those ideas…

You do not need to write any project-specific definition for OBJS. You can include in the project Makefile a generic Makefile that may contain a definition like: OBJS := $(CPP_FILES:.cpp=.o) $(CXX_FILES:.cxx=.o) $(CC_FILES:.cc=.o) \ $(C_FILES:.c=.o) $(SS_FILES:.S=.o) $(S_FILES:.s=.o) $(F_FILES:.f=.o) \ $(L_FILES:.l=.o) $(Y_FILES:.y=.o) $(RC_FILES:.rc=.o) $(O_FILES) which builds an OBJS list from all the lists of sour…

This is simple enough if you're okay with intermediary files littering the entire codebase. Targets and their intermediary files will be written right next to their sources and the whole tree will be a huge mess.

The makefile quickly gets complicated if one wants an organized source tree such as:

  source/module/file1.c
  source/module/file2.c
  source/main.c
  source/tools/tool.c
To be transformed into an architecture specific build tree whose organization automatically matches that of the source tree:

  build/$arch/prerequisites/module/file1.d
  build/$arch/prerequisites/module/file2.d
  build/$arch/prerequisites/main.d
  build/$arch/prerequisites/tools/tool.d
  build/$arch/objects/module/file1.o
  build/$arch/objects/module/file2.o
  build/$arch/objects/main.o
  build/$arch/objects/tools/tool.o
  build/$arch/executables/main
  build/$arch/executables/tool
The general solution to that is the explicit path method:

https://make.mad-scientist.net/papers/multi-architecture-bui...

Post reply on HN