3 ms·

> The downside of this approach is that you will need to keep the Makefile updated with the new files you add to the project so that they are compiled and linke

> The downside of this approach is that you will need to keep the Makefile updated with the new files you add to the project so that they are compiled and linked correctly. Does it? IIRC something like build/%.o: src/%.c include/*.h $(CC) -c $(CFLAGS) $(CPPFLAGS) -c -o $@ $< works well enough for small projects.

seabass-labrax 3y ago
You don't even need to specify that rule with GNU Make: building %.o is a built-in rule[1]. Personally, I tend to prefer specifying the files individually - it doesn't take up that much developer time nor much space in your Makefile, and makes it considerably easier to debug building issues when using a sandboxed environment (such as Nix or Bazel). [1]: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html#index-C_002c-rule-to-compile https://www.gnu.org/software/make/manual/html_node/Catalogue...
- Joker_vD 3y ago
  Doesn't the built-in rule put files in the wrong folder? That is, the same folder the source file is in?
  - seabass-labrax 3y ago
    Yes; I've just tested it on GNU Make 4.3 and you are quite right. It only works when the *.c files are in the directory where object files are referenced. E.g.: example: build/blah.o echo nothing special .PHONY: example ...requires blah.c to be in build/.
  - cozzyd 3y ago
    You can probably use VPATH as a hack
lsllc 3y ago
I use make's `wildcard`, for example to locate all of my unit tests with the project sources (I don't use a `test` subdir): TEST_SRC = $(wildcard *_test.c) If you follow TFA's guidelines about having a `src` dir, then: SRC = $(wildcard src/*.c) And if you need to convert that to a list of matching .o files, `patsubst` is your friend: OBJ = $(patsubst %.c,%.o,$(SRC)) So now simply dropping a file into the right place (or a unit test ending in _test.c) won't require any makefile changes. I tend to copy my most recent Makefile into my next project and generally it stays 90% the same (I have to edit a few macro definitions and rules, but not many).
deleted 3y ago
[deleted]

seabass-labrax 3y ago

You don't even need to specify that rule with GNU Make: building %.o is a built-in rule[1]. Personally, I tend to prefer specifying the files individually - it doesn't take up that much developer time nor much space in your Makefile, and makes it considerably easier to debug building issues when using a sandboxed environment (such as Nix or Bazel). [1]: https://www.gnu.org/software/make/manual/html_node/Catalogue-of-Rules.html#index-C_002c-rule-to-compile https://www.gnu.org/software/make/manual/html_node/Catalogue...

Joker_vD 3y ago
Doesn't the built-in rule put files in the wrong folder? That is, the same folder the source file is in?
- seabass-labrax 3y ago
  Yes; I've just tested it on GNU Make 4.3 and you are quite right. It only works when the *.c files are in the directory where object files are referenced. E.g.: example: build/blah.o echo nothing special .PHONY: example ...requires blah.c to be in build/.
- cozzyd 3y ago
  You can probably use VPATH as a hack

lsllc 3y ago

I use make's `wildcard`, for example to locate all of my unit tests with the project sources (I don't use a `test` subdir): TEST_SRC = $(wildcard *_test.c) If you follow TFA's guidelines about having a `src` dir, then: SRC = $(wildcard src/*.c) And if you need to convert that to a list of matching .o files, `patsubst` is your friend: OBJ = $(patsubst %.c,%.o,$(SRC)) So now simply dropping a file into the right place (or a unit test ending in _test.c) won't require any makefile changes. I tend to copy my most recent Makefile into my next project and generally it stays 90% the same (I have to edit a few macro definitions and rules, but not many).

deleted 3y ago

[deleted]