Note that having recursive make is often a bad pattern, there's an online article on this, having a single makefile with all the dependency edges lets Make work much better.
However, please note that the root build system of an operating system *is distinct* from the build system of the main components. It has all sorts of logic that doesn't belong at any lower level. The points against recursive make doesn't quite apply here. In my meaty skeleton wiki article, I actually write the root build system in shell scripts to make the distinction visible.
I suppose it is OK to have libc and the kernel and all the user-space programs and libraries in the same dependency graph, but I doubt how much this scales in practice. Using things like -MD and such seems to work well in each component in my OS. I don't have all the answers here though, I am switching to my own make implementation soon that has a feature set better adjusted to my needs and scale. The recursive make design really doesn't play well with the strengths of make.
I think make is fundamentally a good design. I don't like tools generating makefiles or trying to abstract them away. The standard unix command line tools for stuff like compiling already provide suitable abstractions. I think make can be a good deal better with some smaller improvement without throwing away the language or design (or compatibility with many existing makefiles) (just some implementation may need to go away).You may disagree with these premises, in which case good for you.
When we're talking about that, might I point to JAWS. I use that CMake setup at the office to build the same project...
On Linux to either "make install" directly or "cpack" either DEB or RPM packages
On Linux using MinGW (MXE.cc, to be exact) to generate a setup.exe for Windows (both 32 and 64 bit)
On Windows using Visual Studio / nmake to either "nmake install" directly or "cpack" a setup.exe
On Windows generating a Visual Studio solution
On Windows using Cygwin / gcc
On AIX / IBM xlc compiler
It also generates Doxygen-based source documentation, LaTeX-based documentation, does code formatting tests, unit tests, and supports continuous / nightly builds including reporting to a web-based dashboard. While it's not perfect, and the online version is lagging a bit compared to the version I employ at the office (as I hadn't found the time to merge back the latest changes), it's a very good starting point, if I may say so myself.
I have positively no idea how well CMake applies to building a kernel, but for the user space, it is quite capable.
Every good solution is obvious once you've found it.
Solar wrote:I have positively no idea how well CMake applies to building a kernel, but for the user space, it is quite capable.
The only problem I have experienced is cmake doesn't seem to handle .s/.S files well -- It may be my inexperience - but I usually just add_custom_target() with a NASM command.... you can add dependencies and GENERATES clauses to integrate the assembly into the make dependency tree.
Plagiarize. Plagiarize. Let not one line escape thine eyes...
Note that having recursive make is often a bad pattern, there's an online article on this, having a single makefile with all the dependency edges lets Make work much better.
However, please note that the root build system of an operating system *is distinct* from the build system of the main components. It has all sorts of logic that doesn't belong at any lower level. The points against recursive make doesn't quite apply here. In my meaty skeleton wiki article, I actually write the root build system in shell scripts to make the distinction visible.
I suppose it is OK to have libc and the kernel and all the user-space programs and libraries in the same dependency graph, but I doubt how much this scales in practice. Using things like -MD and such seems to work well in each component in my OS. I don't have all the answers here though, I am switching to my own make implementation soon that has a feature set better adjusted to my needs and scale. The recursive make design really doesn't play well with the strengths of make.
I think make is fundamentally a good design. I don't like tools generating makefiles or trying to abstract them away. The standard unix command line tools for stuff like compiling already provide suitable abstractions. I think make can be a good deal better with some smaller improvement without throwing away the language or design (or compatibility with many existing makefiles) (just some implementation may need to go away).You may disagree with these premises, in which case good for you.
I have based my hobby os organization in meaty skeleton wiki article (are you meaty skeleton wiki article author? If so, thank you because it help me a lot). The only thing I am doing is to build it from Makefile tool.
In my original post I copy/paste a Makefile main excerpt. The complete Makefile is:
PROJECTS=libc kernel
# CURDIR is set when makefile starts and its value is the current directory.
SYSROOT?="$(CURDIR)/sysroot"
ARCH="i686-elf"
CC=$(ARCH)-gcc
LD=$(ARCH)-ld
AR=$(ARCH)-ar
.PHONY: projects
projects: sysroot-dir
for dir in $(PROJECTS); do \
CC=$(CC) LD=$(LD) AR=$(AR) DESTDIR=$(SYSROOT) PREFIX="/usr" $(MAKE) -C $$dir; \
done
sysroot-dir: | $(SYSROOT)
$(SYSROOT):
mkdir -p $(SYSROOT)
.PHONY: clean
clean:
rm -f myos.iso
for dir in $(PROJECTS); do \
$(MAKE) -C $$dir clean; \
done
There's not much that you could've screwed up there since that makefile doesn't even do any of the things make is intended for. At this point, it might as well be a shell script.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
