OSDev.org

Posted: **Fri Jan 20, 2017 12:35 pm**

Hi folks,

I am trying to build a project with Makefiles. I need to launch two Makefiles inside two folders. Nowdays I do this:

Code: Select all

PROJECTS=libc kernel

.PHONY: projects
projects:
    for dir in $(PROJECTS); do \
        CC=$(CC) LD=$(LD) AR=$(AR) $(MAKE) -C $$dir; \
    done \

Is this ok? Is there any other method to launch Makefiles inside several directories or is this approach the better one?

Thank you.

Posted: **Fri Jan 20, 2017 1:05 pm**

seems OK

but as you refactor your dir organization it gets tiring...

I use CMake which shields me from this though....

http://www.cmake.org

very simple example: https://cmake.org/examples/

a very complex example: https://github.com/llvm-mirror/libcxx/b ... eLists.txt

totally worth learning.

cheers

Posted: **Fri Jan 20, 2017 2:00 pm**

That approach is fine.

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.

Posted: **Fri Jan 20, 2017 2:07 pm**

@sortie +1 with the exception that autotools abstracts away make as well.. and that is a train wreck.

Enough large projects use cmake to give it a valid look though.

As well as cmake does a good job of dealing with cross compiler management

cheers

Posted: **Fri Jan 20, 2017 3:14 pm**

You can see how to set up cmake for a) host compiling tools, b) cross-compiling kernel, c) cross-compiling your OS app, here https://github.com/berkus/metta/blob/de ... eLists.txt

Posted: **Sat Jan 21, 2017 9:02 am**

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.

Posted: **Sat Jan 21, 2017 3:05 pm**

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.

Posted: **Sat Jan 21, 2017 3:08 pm**

Solar wrote: When we're talking about that, might I point to JAWS

WOW - THANKS! - THIS WILL NICELY WORK WITH MY SETUP!!!!! THANKYOU

Posted: **Sun Jan 22, 2017 5:09 am**

Thank you very much for your comments.

sortie wrote:That approach is fine.

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:

Code: Select all

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

Posted: **Mon Jan 23, 2017 7:41 am**

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.

OSDev.org

Makefile question.

Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.

Re: Makefile question.