Makefile Question

[MuchLearning]

Looking through the MeatySkeleton example and noticed that the makefile for libc manually lists all the object files in sub directories like this

Code: Select all

FREEOBJS=\
$(ARCH_FREEOBJS) \
stdio/printf.o \
stdio/putchar.o \
stdio/puts.o \
stdlib/abort.o \
string/memcmp.o \
string/memcpy.o \
string/memmove.o \
string/memset.o \
string/strlen.o \

libk.a: $(LIBK_OBJS)
	$(AR) rcs $@ $(LIBK_OBJS)

As the project grows in size this will become more and more tedious to maintain. Surely there is a way to tell Make about a directory and have it grab all object files in said directory?

Any help is appreciated, thanks.

[MuchLearning]

Would something like this work?

Code: Select all

$(shell find . -name *.o)

[StudlyCaps]

Your snippet won't work I think, because you're searching for existing .o files which won't have been generated yet (.o files are intermediate results of compilation). At least it won't work on a clean build.

Generally, most build systems require you to explicitly define all targets, getting clever with autodetecting tends to introduce hard to find bugs in the build process. A decent compromise though is to use the include directive in your Makefile to separate out your list of .o files from the main build directives.

In your example, you might put a file in each directory (for example "stdio/mkconfig", "stdlib/mkconfig", "string/mkconfig") in the mkconfig files you can append to the FREEOBJS variable (FREEOBJS += stdio/printf.o stdio/putchar.o stdio/puts.o) then in your main Makefile simple put one "include <dir>/mkconfig" for each sub-directory.

Then the file listing the .o files is kept with the source .c files, and each one has a smaller list which is easier to maintain.

As far as it getting tedious, it can be, but typically once you've established the structure of a project you spend much more time editing existing files than adding new ones and it only takes a second to add another line to define a new dependency.

[MuchLearning]

Thanks! This is probably what I will do.

Just for fun though, I think I found something that almost works for including all possible object files.

Code: Select all

$(patsubst %.c,%.o,$(wildcard *.c))

From GNU Make Docs, this should select all .c files using the wildcard function, then replace the .c file extensions with .o, thus generating a list of all obj files from c files?

Even if this works it isn't recursive though and each directory would have to be specified by hand. Unacceptable!

[StudlyCaps]

That is a cool function. I always meant to learn more about make's string manip. functions, but when I come to use them in actual projects though I almost always end up finding some special case that needs to be handled and I just give up and declare everything explicitly.

[Solar]

I have used find and wildcarding myself, so this is very much a case of "do as I say, not as I do".

But listing all source files *explicitly* has its advantages.

For one, you get notified if one of the source files has been moved, renamed, or deleted. That might have been unintentional, and could have subtle impacts on your product.

Second, you might be looking at temporary stuff, like generated sources, "testme.c" one-offs and similar, which you don't *want* to be caught by your generic Makefile rules.

I'm not saying that find / wildcard are bad, or shouldn't be used. Just be aware what you're doing.

(Today I am using JAWS / CMake, and *do* list each source file and header file individually.)

[Sik]

There's also the part where you explicitly need to make rules for each .o file anyway just to indicate their own dependencies (usually its matching .c file and the non-system header files it includes), so it's not like you completely avoid the headache (not to mention having to keep them up to date in case the dependencies ever change, e.g. an #include was added to the source file). It'd be more useful to get a list of .o file with a rule (and even then it assumes you want to include every single .o file, which is probably not the case for anything with multiple targets).

At this point it's easier to just generate the makefile automatically to ensure everything is kept up to date (which is what all those building tools like cmake ultimately aim to do).

[obiwac]

This may be entirely subjective, but I personally prefer having control on what files I want linked. For example, if you have a file that is not finished, and you start work on something else, it's nice to not have it crash your os or something like that.

[eryjus]

For me personally, I despise maintaining my makefiles with each file addition/deletion/movement. I'm far more apt to forget to make the additional changes than I am to have a problem with linking the incorrect object. Also, running `make xxxx` is very tightly integrated into my iterative development workflow, where I could easily run make a hundred times a day just as a spell-checker. Instead, I would rather spend my makefile time working on the rules for a distinct target and what that all entails, so that if I add a file in to a location, it just works; if I move a file, it just works. If I move a header, well I have to run `make clean` first to address the dependencies, but then it just works.

That does not imply that my makefile is simplistic -- quite the contrary. But, I do not have to maintain it with every change I make. I would like to believe that I have a pretty robust build system as a result. You can see it here: https://github.com/eryjus/century/blob/master/Makefile

[obiwac]

Good point. You made me rethink my workflow.

[Solar]

There's also the part where you explicitly need to make rules for each .o file anyway just to indicate their own dependencies (usually its matching .c file and the non-system header files it includes)...

You do know about things like GCC's -MMD -MP option giving you the header dependencies of a source file, as a side-effect of compilation? If you did not know, check the Makefile tutorial in the OSDev Wiki (Dependencies pt. 1 through pt. 3). There are reasons to have explicit rules for specific object files, but header dependencies shouldn't be among them. (And no-one is better at figuring them out than the compiler.)

[Octocontrabass]

(And no-one is better at figuring them out than the compiler.)

Except maybe tup.

[Solar]

Well, what the compiler is actually including is what counts regarding logical dependencies, and no-one -- not even tup -- knows better what the compiler includes than the compiler itself.

[dozniak]

According to tip docs it instruments file opening and as such also knows all files open by the compiler, not only direct depwndencies but perhaps library files and other binaries.

[Solar]

And while a commendable effort, it is still being educated guesswork. The -M options are making the compiler tell what it's doing, with regards to header files.