i should probably learn how makefiles work some day

[srazkvt@tech.lgbt]

@eniko it's a bit abstract, so it's easier with an example: you have a makefile with three jobs, two for two c files, lib.o and main.o, which depend respectively on lib.c and main.c, and one that will link the two together into an executable (say, prog)

lib.o: lib.c
    gcc -c lib.c

main.o: main.c
    gcc -c main.c

prog: lib.o main.o
    gcc -o prog lib.o main.o

here, when you run make prog, make will first check wether lib.o needs updating. maybe it wasn't updated manually, but it is a job in make, and that job also gets checked. if the c file was modified, then lib.o will be regenerated, otherwise, it won't. then, make will do the same with main.o (and main.c).

if any of them was updated, then prog will run its own tasks, and produce the prog binary, and otherwise, will just tell you there's nothing to do.

[snowfox@tech.lgbt]

@eniko They're nice when you want more than a shell one-liner but don't want a fancy build system. (I basically never want a fancy build system.)|

[srazkvt@tech.lgbt]

@eniko make also has some niceties to handle configurability of the build, and to reduce boilerplate, but those are just for that, reducing boilerplate, and aren't fundamentally necessary to how make works. a fair few systems will also just generate makefiles or ninja files (which are basically the same but stripped down, which can improve compile performance for large projects) because configurability in make is generally a mess, and is done more easily with an external tool, like meson or cmake or autoconf

[srazkvt@tech.lgbt]

@eniko people really make it to be more complex than it really is, but honestly the parts that are hardest to deal with are the configurability and boilerplate reduction parts, which ... yeah, messy is the nicest way i can describe them

[specter@eattherich.club]

@dabe @eniko functionally Make is great but it's brutalist markup, not at all easy to get a grip on.

[eniko@mastodon.gamedev.place]

Wait. Is cmake make? Or are they different things

[dotstdy@mastodon.social]

@eniko completely different, but cmake can generate make files.

[clarfonthey@toot.cat]

@eniko cmake ostensibly was a system to make makefiles but I don't think it does that any more and just has its own way of building stuff

[mkj@social.mkj.earth]

@dotstdy Well, make and cmake do solve the same problem, don't they?

@eniko

[runner@mastodon.art]

@eniko cmake makes make for c but you can make not make for not c

[zinnschlag@mastodon.gamedev.place]

@eniko Different things. CMake can create makefiles. Or project files for IDEs. Kinda like an additional abstraction layer.

CMake is slightly less gnarly than make, but still not fun.

[dotstdy@mastodon.social]

@mkj @eniko not really, cmake is a generator for 'make-like' things. Make is a thing which you use to actually execute a build.

[voidstarkat@unstable.systems]

@eniko cmake is it's own thing, it can do a lot more things, but a lot more complicated

[makiki@bark.lgbt]

@eniko different, IIRC cmake generates a makefile for make (please don't quote me on that, it was a while since manually I built something using make from source)

[cliftonr@wandering.shop]

@mkj @dotstdy @eniko

They create the same problem, if that's what you meant to say?

[clarfonthey@toot.cat]

@eniko make is kind of a mess, but very simple to learn, honestly

GNU make has a full manual online I've referenced frequently

the important bit to understand is that it is very based in traditional C building where each .c file is compiled into a .o file and then linked

so, it effectively does a topological/tree sort of dependencies where when you ask "make binary" it goes:

1. is binary newer than its dependencies? (by file modification time?)
2. are those dependencies newer than their dependencies?
3. etc.

and then builds the stuff as necessary. it also lets you parallelise which is cool

the most complicated bit is "phony" targets where instead of an actual file, you say something like "make build" which always runs commands and/or builds dependencies

also, load-bearing tabs; space-indenting doesn't work

[shanecelis@mastodon.gamedev.place]

@eniko Different and bleh but better than automake.

Build tools are a mess each generation must create their own flavor of dissatisfaction that they get used to—you know, like fashion.

[srazkvt@tech.lgbt]

@eniko cmake is really a bad name, it is very different from make. yea, as other comments said, it generates makefiles from a cmake definition, and does extra things like managing subprojects and stuff iirc

what really doesn't help is there is bmake, which is a make implementation from the BSD operating systems, and gnu make is often referred to as gmake, so it is a reasonable assumptions that cmake would also be a make implementation, but, yea, no

[duke_of_germany@mastodon.gamedev.place]

I looked into cmake a couple of times, but it seemed to bring so much complexity of its own.

I think it can make things easier (or at least quicker) when you want to pull in a ton of dependencies, which it can download & build for you.

My projects only have very few dependencies, so I just put in the time to write a versatile Makefile that works with all my projects.

How are you building your projects at the moment?

@eniko

[clarfonthey@toot.cat]

@eniko also like, the reason why external systems like cmake exist is because, specifically for the purpose of making C code, plain make is a pain in the absolute ass

while header files make dependency lookup relatively easy, make does not do that, and so you either have to just force-rebuild parts if you modify a header file or manually list all dependencies and update them when they change

so, cmake will figure that out for you, and so will ninja, etc.

but makefiles are still really good in any build system, because if you have a way of outputting the dependency tree into a file and the right commands you can just have make figure out how to run and parallelise it for you