OSDev.org
https://forum.osdev.org/

Makefile question.
https://forum.osdev.org/viewtopic.php?f=13&t=31272
Page 1 of 1

Author:  rgmf [ Fri Jan 20, 2017 12:35 pm ]
Post subject:  Makefile question.

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:
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.

Author:  dchapiesky [ Fri Jan 20, 2017 1:05 pm ]
Post subject:  Re: Makefile question.

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

Author:  sortie [ Fri Jan 20, 2017 2:00 pm ]
Post subject:  Re: Makefile question.

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.

Author:  dchapiesky [ Fri Jan 20, 2017 2:07 pm ]
Post subject:  Re: Makefile question.

@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

Author:  dozniak [ Fri Jan 20, 2017 3:14 pm ]
Post subject:  Re: Makefile question.

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

Author:  Solar [ Sat Jan 21, 2017 9:02 am ]
Post subject:  Re: Makefile question.

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.

Author:  dchapiesky [ Sat Jan 21, 2017 3:05 pm ]
Post subject:  Re: Makefile question.

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.

Author:  dchapiesky [ Sat Jan 21, 2017 3:08 pm ]
Post subject:  Re: Makefile question.

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



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

Author:  rgmf [ Sun Jan 22, 2017 5:09 am ]
Post subject:  Re: Makefile question.

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:
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


Author:  Love4Boobies [ Mon Jan 23, 2017 7:41 am ]
Post subject:  Re: Makefile question.

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.

Page 1 of 1 All times are UTC - 6 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/