OS Makefile Design - Recursive or not

[thepowersgang]

I'm planning on rewriting my OS's build system from being based on recursive make, with each application/driver having its own makefile that includes common configuration makefiles further up the tree, into a single make call which compiles the entire OS on its own (with per-application settings/objects handled with config makefiles in each directory).

My question is, Is this a good idea? Or should I have one makefile for the kernel mode build and one for usermode? Or keep it as it is, invoking many different make processes.

The currrent system takes ~50s to recompile (`make all install`) from clean on my Atom N450 netbook, and 2s to run `make all install` on a fully remade tree, and compiles about 40 different binaries.

What does everyone else use, and how well does it suit you?

[Love4Boobies]

Your build system's structure should be similar to the one you have now, except you should include "child" makefiles instead. As for the second question, they can have multiple targets so you could get different components built for "make" (or "make all"), "make kernel", and "make foobar".

[Solar]

Makefile is what I use. Non-recursive, definitely. Doesn't make much sense to have a dependency-checking build system, but not telling it about the whole build tree, does it?

[thepowersgang]

I agree with the ideas from that article, but my issue is handling different compilation flags. Usermode applications take very different CFLAGS/LDFLAGS to kernel modules.

Can you think of a good way of compiling each module using the required settings? I just thought of using a suffix on the object file, but that may not work nicely.

EDIT: Clarifcation

My current system allows me to compile the entire OS and install it to a FAT floppy (via mtools) so has to cope with multiple different areas, not just the kernel/modules, which could be relatively easily handled with a singe make process.

[Combuster]

I use nonrecursive make as well and it does exactly what it needs to do. Recursive make would get ugly with the web of (false) dependencies you generate. If I change a sourcefile in the C library I only need to recompile that file and relink the binaries, not do a full recompile of all userland code I can find.

It's not too difficult to specify per-task rules using make.

[Solar]

It's not too difficult to specify per-task rules using make.

That's the point. It shouldn't be too difficult to specify seperate sets of compiler flags, and using one set in general rules and another in rules specific for a subdirectory.

The oft-abused variable name CFLAGS - which I guiltily admit using in the Makefile tutorial - is a bad practice anyway. CFLAGS is meant for user specified flags, as in:

Code: Select all

CFLAGS="-DENABLE_SPECIAL_LOGGING" make all

Using CFLAGS as variable for Makefile-internal flags effectively overrules whatever the user did set. That could be a design decision of the Makefile author, but usually it is not.

[ACcurrent]

Am I the only person who uses python scripts?
Seriously I don't know how big your OS is so I cannot tell, but if there are more than 30 file then use a recursive makefile otherwise non-recursive.

[Combuster]

but if there are more than 30 file then use a recursive makefile

You too, young padawan, must read Recursive make considered harmful before making suggestions without arguments.

CFLAGS="-DENABLE_SPECIAL_LOGGING" make all

The downside of having CFLAGS (or whatever you want to named it) out of the makefile, is that you'd often need a construct like CFLAGS="..." make clean && make all to have it actually do what you intend to.

[Solar]

The downside of having CFLAGS (or whatever you want to named it) out of the makefile, is that you'd often need a construct like CFLAGS="..." make clean && make all to have it actually do what you intend to.

Nonononono.... you misunderstood.

Outside the Makefile:

Code: Select all

CFLAGS="-DENABLE_SPECIAL_LOGGING" make all

Inside the Makefile:

Code: Select all

LOCAL_CFLAGS=-Wall -Wextra -Werror -nostdlib -fno-builtin -nostartfiles -nodefaultlibs -fno-exceptions -fno-rtti -fno-stack-protector

%.o: %.c
        $(CC) $(LOCAL_CFLAGS) $(CFLAGS) -c $< -o $@

CFLAGS should be for the user to add to whatever flags the Makefile defines. Originally. One of the many concepts watered down by neglect over the years.

Then again, that's only one "school" of 'make'. Others think and do and recommend different.

[Combuster]

Consider the following use case (or bug report if you like):

$ make all
$ ./app
ENABLE_LOGGING not set
$ CFLAGS="-DENABLE_LOGGING" make all
$ ./app
ENABLE_LOGGING not set
$ CFLAGS="-DENABLE_LOGGING" make clean && make all
$ ./app
ENABLE_LOGGING set

[Solar]

Yes, sure. Overriding CFLAGS is for people who know what they're doing (i.e., run 'make clean' first). The alternative to this is poking around in the Makefile itself.

Anyway, it's a minor point.

[Jezze]

I use non-recursive make too. However they look like puke because I haven't had the time/interest in fixing them. I've heard bad things about recursive makes but I think they make sense when your subfolders can be considered seperate projects like you said that compiling user programs is different from the kernel.

A nice guy forked and created scons scripts for me which I think about using. They seem nice.

[Solar]

If two applications are completely seperate projects, and have no code in common other than including the same kernel's include files, there's nothing wrong with seperate Makefiles. A "recursive" Makefile is something else, it's when you have a Makefile for components of an embracing project. A Makefile per driver, for example, would be a mistake, as I figure they will (and likely should) share quite some common code.

If you find your application Makefiles to be largely identical, you can still use a common Makefile include.