Makefile organization

[Guest]

I have a slight file organizational problem.
Right now i use a makefile to compile the kernel. the problem is that i have a very large line of kernel dependent files
it looks something like this

Code: Select all

KernelFiles= kstart.o pic.o memory.o kernel.o io.o mystdio.o cfloppy.o fdd.o hdd.o rtc.o idt.o timer.o kbd.o

as you can see this is likely to increase very soon. so what i want to know is there any way i can create an intermediate object file such as handler.o which is nothing but a combination of the object files fdd.o hdd.o rtc.o timer.o kbd.o?
I dont want to have to create another file just to "include" all these and then compile. so i guess basically my question is how the hell can i combine object files into a single object file

[df]

you want a library.

check 'ar'. (man ar or info ar).

[Slasher]

Also, when using AR make sure all the object fiiles are in the same format ie

Do not try

Nasm -faout *******
gcc -c ***(coff file is generated)
cause AR will create a bad library file or Not make one at all

instead use
Nasm -fcofff ****
now ASM object files and C objects files are the same.
Hope thic helps

[Guest]

Well i havent used 'ar' before. so where can i find more info on it. I use windows.

[Therx]

STFW

I type into google

ar manual online linker

And third result is

ekkoBSD man pages : ar (1)

The windows port will have the same options etc.

How hard would that have been? >:( Don't take offense but in future I'm sure you could manage this

Pete

[libber]

hi, i just found out how to do this today so don't quote me but i you should be able to use 'ar' and 'ranlib'. ranlib is not neccesary i think but it doesn't hurt

if you want to combine all your object files (as stated they must be of the same format) do 'ar cvr big.o 1.o 2.o 3.o etc.o' then 'ranlib big.o' all your .o files will now be in big.o which you can proceed in as usuial

[Neo]

Is it possible to have a makefile in each subfolder and another one in the parent folder which just calls these *child* makefiles? How do i do call them from the parent?

[Tim]

Code: Select all

OBJS= file1.o file2.o file3.o

all: target subdirs

subdirs:
    make -C subdir1
    make -C subdir2
    make -C subdir3

target: $(OBJS)
    ld -o target $(OBJS)

[Jamethiel]

Code: Select all

subdirs:
    make -C subdir1
    make -C subdir2
    make -C subdir3

Please don't. Consider instead the following:

http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

--Jamethiel

[Therx]

why can't make provide a function so that an object is only remade if it was created before the last modification date of the source file.

Pete

[proxy]

this is precisly what it does...i fyou are referring to the paper, well when you have a recursive make, it needs to go into each sub directory and do a make there too, even if there is no work to do, because the only one who would know is the child makefile. this time adds up, especially for large projects.

personally, i use a lot of makefile trickery to get the job done

but still one way or another, i need to manually list all the .S, .cpp and .c files...

proxy

[Pype.Clicker]

well, recursive makefile will only be harmful if you have veryveryvery much directories and if the cost of starting another MAKE install becomes high ... I don't think any of us are at this level yet ... Also, the "bad things" the author of this paper present (such as having mod1/main.c relying on mod2/header.h and mod2/program linking to mod1/main.c) looks like VeryBadPractice to me ... if something has to be used by many modules in a modular system, that thing should not be bound to a specific module, but rather in some kind of project-wide area (something like /project/include ...)

Recursive makefiles are (imho) a good step towards organization. If something does not fit a recursive make nicely and require hacks, probably there should be something done so that the hack itself is no longer necessary ...

So far, i have recursive makefiles (up to 4 level depths) with some of them that are pretty empty (demonstration modules, for instance) and those work with a single-pass on the tree, including dependencies refreshes and all these work pretty fine, with a "nothing to be done" re-make that takes a maximum of 2 seconds ... Moreover, if i only want to rebuild a given module, i can do it very fast by just callin' "make" on that module's directory.

I admit Linux kernel makefiles are recursive *and* are quite a nightmare ... but that doesn't mean all recursive makefiles are nightmares, does it ?

[nullify]

AFAIK, it wouldn't be too difficult to merely include subdirectories of makefiles instead of recursively invoking make upon them. I'd like to know the following: is there any particular reason to be using recursive make in the first place?

Personally, I use Perforce Jam to manage builds, so I'm not exactly a makefile guru. Please forgive my ignorance if I'm missing something here.

[Pype.Clicker]

Yes, there is one good reason for doing recursive makefiles:

Divide And Conquer

It's more straightforward to create a simple leaf-level makefile that generates binaries for a sub-project than architecturing One Makefile to Build'm All (oops ... i did it again )

Btw, if you prefer creating One Makefile out of many smaller ones with a perl-like script (or using GCC's preprocessor to #include makefile parts), well, that's your choice ... This way you can end with a non-recursive process on a logically recursive structure ... and win on both issues ...
I've never push crazy coding *that* far afaic, though.

[Solar]

Yes, there is one good reason for doing recursive makefiles:

Divide And Conquer

It's more straightforward to create a simple leaf-level makefile that generates binaries for a sub-project than architecturing One Makefile to Build'm All (oops ... i did it again )

Sorry, Pype, but you achieve the same with included makefiles - each of which is for a subproject. It's the recursive call that makes a mess out of things.