OSDev.org

MessiahAndrw wrote:Make is overkill for my simple needs.

$ mkdir hello
$ cd hello
$ echo '#include <stdio.h>\n int main() { printf("Hello, world!\\n"); return 0;}' > main.c
$ make main
cc    main.c    -o main
$ ./main
Hello, world!
$

Candy wrote:what kind of things do you want from a build tool / would make your OS much easier to compile / more reliable / faster ?

b.zaar wrote:I'd like something mixed between a makefile and a shell script, more like a structured function.

Code: Select all

out all(kernel.sys, initrd)

out kernel.sys(mbhead.o, kernel.o)
{
    // linking instructions. All variables are private to this block  

}

out initrd(ata.drv, fbdev.drv, ext2fs.drv)
{
    // Shell commands and more private variables
}

All external commands are handled in a single shell so you could cd to a directory and run the rest of the function from there. Also most commands should be handled by the build program so that it's not relying on a certain shell being installed, kind of like an internal bash environment.

Well max posted before I finished but yeah capri is similar but i don't think is quite the same.

max wrote:I've actually developed a build script lately, named Capri. It's similar to C and Java allows you to define projects that contain tasks & dependencies, import other scripts and use native functions to access stuff. This is a small example that builds all sources in src that end with c or cpp to bin.

Code: Select all

project MyKernel {

    CXX = "i686-ghost-g++";
    CFLAGS = "-whatever";

    system windows {
        CXX = "i686-sucky-cygwin-gcc";
    }

    task all depends check {
        Compilation.executeForChanged("src", {".c", ".cpp"}, "{CXX} {CFLAGS} $file$");
    }

    task check {
        if(!File.isFolder("bin")) {
            clean();
        }
    }

    task clean {
        File.cleanFolder("bin");
    }

}

You can write huge scripts that do a lot of stuff, or simple small things like this one that use the support script.
It's in the alpha/beta phase, and not very many people where interested the last time so I had no real motivation to publish it yet. ^^

CXX = "i686-ghost-g++"
CFLAGS = "-whatever"

(.*)/src/.*\.(?:c|cpp) => \1.exe
  $(CXX) $(CFLAGS) -o $@ $^

CXX = "i686-ghost-g++"
CFLAGS = "-whatever"

(.*)/src/(.*)\.(?:c|cpp) => \1/obj/\2.o
  $(CXX) $(CFLAGS) -o $@ -c $^
(.*)/obj/.*\.o => \1.exe
  $(CXX) $(CFLAGS) -o $@ $^

b.zaar wrote:I'd like something mixed between a makefile and a shell script, more like a structured function.

...

All external commands are handled in a single shell so you could cd to a directory and run the rest of the function from there. Also most commands should be handled by the build program so that it's not relying on a certain shell being installed, kind of like an internal bash environment.

Well max posted before I finished but yeah capri is similar but i don't think is quite the same.

thomasloven wrote: My biggest problem with make is the weird function syntax and the forced hard tabs.
Just a thought: Perhaps a different approach could be a collection of tools that could plug in to shell scripts which fills the space between shell and make - such as dependency tree generation?

Combuster wrote:Though, I won't quit using make if the other utility can't do massive parallism.

threadId = concurrent massiveCalculation(251, 836.51);
// do other stuff in the meantime
// once you need an result:
result = join threadId;

sortie wrote:For the operating system components such as the kernel, libc, utilities and so on, I use Make. This is a good tool for the job as files are obviously derived from each other and can be built in parallel. Therhave is good room for configuration by the advanced user through standard and ccomponent-local environment variables.

I use GNU make and I hate it. It is too poorly written (please seriously read its source codexif you use it) and is too compatible with awful systems, meaning its source code is dumbed down in troublesome manners. I am currently as a low priority project writing my own Make that is much cleaner, is compatible with POSIX, and will new useful features the way I want them.

The top level build system is responsible for building the entire operating system and the ports. This is high level logic and is better suited for shell scripts than Make, as files are not obviously derived from each other. I implement this with make rather than shell scripts for historical reasons. This layer is meant to set up a basic system root, then cross compile each component and port into it. It should then add configuration to the system root and make a bootable image in accordance with the user's wishes.

Your building system should be designed such that building on your OS itself is the primary and simplest platform. Cross compiling is always a secondary platform, make it simple and no simpler. For instance, my makefiles always build the code for the local operating system, even if it doesn't make sense, as many of my programs don't work on Linux. The cross user must explicitly request cross compilation.

Combuster wrote:I use makefiles, with a fair share of repetition because there output directory is an hierarchy of its own, and there needs to be a mkdir for every directory which all the compile rules for that directory have to depend on.

(.*)\.cpp => Out/$(OS:Linux CombusterOS)/$(BUILDTYPE:Debug Release)/$(MODE:kernel user)/\1.o
  $($(OS)-CXX) $(CCFLAGS-$(BUILDTYPE)-$(MODE)) -c -o $@ $^

What's also very useful is a way to reliably pick one possible source for an object file. As in, pick the most applicable of { generic/tri.c, x86_mmx/tri.asm, neon/tri.asm } to make tri.o, and a somewhat more-legible-than-perl way of specifying all .c files turned to .o files, perhaps macro-ish, would be very welcome.

Though, I won't quit using make if the other utility can't do massive parallism.

max wrote:@Candy ah okay, your tool is more about writing smaller scripts but allowing complexity. Mine is more about readibility and comfort

Combuster wrote:Though, I won't quit using make if the other utility can't do massive parallism.

capri can! you can use "concurrent <statement>" to start anything in an extra thread. for example

Code: Select all

threadId = concurrent massiveCalculation(251, 836.51);
// do other stuff in the meantime
// once you need an result:
result = join threadId;

hehe now ill stop advertising i promise

Candy wrote:More legible than perl is pretty hard, if you still want the power a regex can provide.

Selecting the most applicable is pretty hard to do. Switching between x86_mmx and neon is easy, if they match your build configs - just compile the asm file to the relevant output dir's obj location and it'll be taken into account for linking.

-j<number of cores> is implied, but you can tune it down if you want to.