Hi all, I'm getting to the point that my directory structure and build process need to be--cleaned up. I was wondering how all of you organize your source tree and build process.
One thing that particularly bothers me about my setup is currently to build my boot floppy I have a local Makefile run dd to put my bootloader C (gcc) and assembly (fasm) binary files together. It's a rather ugly process and I'm sure I'm using a stupid method. How do you all build your boot stuff?
I've been tempted to write something small myself (to use in place of dd) but I figure there must be a better method than I'm currently using.
Thanks.
Your OS Management
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
http://dimensionalrift.homelinux.net/co ... wsesources
Its basically, one directory for each component: one for the kernel, one for the drivers, and various directories for each of the libraries (C Library, Basic Runtime Library, kernel interfaces, low level stuff etc).
Still, GNU make isn't the worlds biggest wonder so you shouldn't expect too much of it. Even I use some crazy stuff to make things work.
nevertheless, i can do anything by typing in make (something). A lot of it will probably not work on all machines though. Still its pretty nice to type "make run" and it'll do everthing up to starting the emulator
Its basically, one directory for each component: one for the kernel, one for the drivers, and various directories for each of the libraries (C Library, Basic Runtime Library, kernel interfaces, low level stuff etc).
Still, GNU make isn't the worlds biggest wonder so you shouldn't expect too much of it. Even I use some crazy stuff to make things work.
nevertheless, i can do anything by typing in make (something). A lot of it will probably not work on all machines though. Still its pretty nice to type "make run" and it'll do everthing up to starting the emulator
I used to use a really complicated Long File Name structured hierarchy with about a hundred levels because i decided to spend my first day OS programming trying to define the structure like that instead of knowing how it would all actually fit together...
it went sonething like
OS Name
-Project Files
--Project Source
---Core
----Kernel
-----Kernel Core
------Subsys 1
etc..
My point being.. it doesnt really matter until you need it... my current OS project had all files in a single folder for 6 months before i created two or three folders for the basic segmentation of files... just do it as you need
it went sonething like
OS Name
-Project Files
--Project Source
---Core
----Kernel
-----Kernel Core
------Subsys 1
etc..
My point being.. it doesnt really matter until you need it... my current OS project had all files in a single folder for 6 months before i created two or three folders for the basic segmentation of files... just do it as you need
Again, I have a base directory (OS Name) and a separate subdir for boot loader, second stage loader, kernel, drivers and documentation.
I am using a batch file to build everything in each subdirectory (I am usually changing only one module at a time), and a batch file in the root dir that builds the whole thing.
The use of filename wildcards has meant that to add a new file to the kernel, I just have to create a file with a .c extension in that subdir and it gets compiled and linked without having to update the batch file.
Adam
I am using a batch file to build everything in each subdirectory (I am usually changing only one module at a time), and a batch file in the root dir that builds the whole thing.
The use of filename wildcards has meant that to add a new file to the kernel, I just have to create a file with a .c extension in that subdir and it gets compiled and linked without having to update the batch file.
Adam
Roughly:
Code: Select all
/usr/src/Pexio
/usr/src/Pexio/Documentation
/usr/src/Pexio/Documentation/Design
UML diagrams (finally :P)
General notes to myself
A few documents detailing loading procedures, boot process etc.
/usr/src/Pexio/Documentation/Technical Manual
A few documents to myself as to what interfaces I present etc -
so I can add to it, or eventually write some usermode stuff.
/usr/src/Pexio/Code
Contains makefile - might make this recursive at some point
/usr/src/Pexio/Code/syscore
Contains the rather minimalist (by design) core kernel stuff that's
loaded initially
/usr/src/Pexio/Code/syscore/include
Guess :P
/usr/src/Pexio/Code/drivers
Will contain further folders with driver modules that I'll load at
runtime
/usr/src/Pexio/Code/drivers/include
Placeholder at the moment, effectively. Will contain the includes
needed to produce a driver. Not quite sure exactly how I'll be
doing this yet, still thinking on that, but hey.
/usr/src/Pexio/Code/console
Pretty much an empty folder for now... will have similar layout to
the others when I get round to being able to write a console for it.
Regards,
Angus [Óengus] 'Midas' Lepper
Angus [Óengus] 'Midas' Lepper
I have in mine...
/
/include
/lib/
/documentation
/extras (unrelated stuff that's there but not needed)
/kernel (all the main sys stuff)
apps/ (test applications)
asm/ (all my asm code)
depricated/ (stuff that's still useful but discontinued)
drivers/ (just about any device stuff)
/.objs (to keep my / dis rather tidy)
[.objs are sorted by folder so all those folders above are also here]
my OS is still very small though..(less than 10,000 lines of actual code)
/
/include
/lib/
/documentation
/extras (unrelated stuff that's there but not needed)
/kernel (all the main sys stuff)
apps/ (test applications)
asm/ (all my asm code)
depricated/ (stuff that's still useful but discontinued)
drivers/ (just about any device stuff)
/.objs (to keep my / dis rather tidy)
[.objs are sorted by folder so all those folders above are also here]
my OS is still very small though..(less than 10,000 lines of actual code)