OSDev.org

How can I make different versions of my kernel?

I want to compile my kernel for different CPUs (i586,i686 and so on), but how can I make this in 1 makefile w/o writing the rules for every single c file?

Many different architectures require different (or modified) code.

Creating a directory tree to separate them and then having a different object list for each arch in the makefile can help.

-JL

You can have a look at the makefile system in my OS - it does pretty much that. In fact, it got some dummy rules to change the default behaviour and make my life easier.

source browser

I think you don´t get what I want.

I want to make object files which are optimized for different cpus (mmx,sse and so on), but these are built out of the same source files.

At the moment I build it like this: But how do I write a Makefile which compiles the source list but outputs different object files (made out of the same source file, like kernel.c -> kernel_mmx.o kernel_sse.o ...). I only need the object files, because I link them together in my bootloader.

The output file will be for your computer.

To compile for different CPU's, the file format doesn't matter, as long as your bootloader loads it.

The code matters, because different CPUs require different code.

-JL

I don't think that's what he's asking for. It sounds like he wants "make sse" to add "-DSSE" to his CFLAGS, "make mmx" to add "-DMMX" to his CFLAGS, etc.

@niteice

This is not really what I want, but it is a good idea for solving my problem. I could write a script which will call my Makefile with different parameters.

@all

I set the vars "CFLAGS" and "LDFLAGS" for the compiler. Is it possible to do this outside the makefile? So I could write a sh script which sets the vars for what I need (so I could also change the output filename) and call my Makefile sometimes.

Another solution I came across is, having different Makefiles, but how to do that. I haven´t used make for so long. So it is possible to have a makefile which isn´t named "Makefile"?

Environment variables override makefile variables. Set the CFLAGS environment variable to any value you like and then call make.

You can also resort to recursive (yuck) make

I run over a new problem. To make gcc able to optimize better I want to give it a list of source files. The problem is now how can I write the dependency list of files, because with the call to gcc -MM it creates a target for every source file and this is not what I want.

The only good solutions for my problems is that I write a script which compiles my code! Another solution is another make program like jam (I tried it but failed to make it do what I want). Is there any good make alternative?

I've used Scons a bit in the past. 'Not bad. It does require Python, however, which can make compiling your code difficult for people without it.

CMake is also popular. (IIRC, Pedigree, an OS project here, uses it.)

Alboin wrote:I've used Scons a bit in the past. 'Not bad. It does require Python, however, which can make compiling your code difficult for people without it.

CMake is also popular. (IIRC, Pedigree, an OS project here, uses it.)

It most certainly does. Requires the latest CVS build and a perl script to generate build flag dependencies but it works fine for us. (And we build multiple target architectures).

Check out our base CMakeLists.txt here, the one that builds the kernel here and the script that generates build flag dependencies here (with input and output files)

FlashBurn wrote:...the call to gcc -MM [...] creates a target for every source file and this is not what I want.

Erm... may I ask why this is not what you want? (I have a hunch there's a misunderstanding of what those "targets for every source file" imply. I believe they are exactly what you want - a list of dependencies for each object file so that 'make' can figure out what exactly needs to be done instead of doing unnecessary work, or omitting necessary work.)

I think/hope that gcc can better optimize the code when I give it a list of src files instead of compiling all src files for their own (this is also a big minus for c or high level languages, you have code which maybe isn´t used).

At the moment I try to use different makefiles for different targets. It is the easiest way.

FlashBurn wrote:I think/hope that gcc can better optimize the code when I give it a list of src files instead of compiling all src files for their own.

To the contrary...

GCC (and all other compilers I ever worked with) work on translation units. Usually, that is a single .c/.cpp file, which might include other files. Each translation unit gets compiled and becomes an object file (.o). (I'm skipping the preprocessor / compiler / assembler distinguation here.)

One or more object files can be linked to become either a shared object or an executable.

Now, the catch is: The compiler has no way to tell which functions of the object file might be needed during subsequent linking. Only the linker has all the information required, it knows exactly which functions are needed in an executable, and it is trivial for the linker to omit object files that are not required. Smart compilers might be able to figure this out, but I wouldn't really count on it.

Thus: Keep your translation units (.c / .cpp files) small, putting only stuff that is interdependent into one file, and stuff that does not depend on each other into different files.

Putting all source files into a single GCC invocation also means you have to recompile all of them each time you touch one of the source files, which pretty much defeats the whole purpose of a Makefile...