OSDev.org

After several cataclysmic typos of the "rm *.c" form instead of "rm *.o", I decided to restructure my build process and put it into makefile form and separate src and build directories. I thought I would post what I did here, so that any other beginners can avoid deleting all their source code.

The setup will be as follows:

OSdir
|
| Makefile
| -- src
| | Makefile
| | -- srcfiles.c
|
| -- build
| | -- kernel
| | -- other object files


Here is the makefile that should go into the top of your OS directory. It will go into the source directory and build sources, link all the object files together, and provide an option to clean up all those pesky object files when you're done with them.

I generalized the C compiler and linker, as well as flags and the directory that your floppy image (that's what I use at least)


Then put this makefile into your src directory:

This makefile will compile all the source files and place their build objects into the build directory. Again, the C compiler and flags have been genericized, so you can put your own in where needed.
Hope this helps someone out. I've just gotten sick of accidentally typing *.c instead of *.o, which has happened to me several times. Enjoy!

A batch program does the trick for me, under Windows.

Hi,

Have you seen Solar's Makefile tutorial on the wiki? I always use that as a template now and the really good thing is that it will recompile source when relevant dependencies (including headers) are updated.

Cheers,
Adam

Thanks, AJ, for the compliment.

@ samoz:

Your problem is probably better solved by a Version Control Software (Subversion, CVS, or even RCS) than a Makefile...

Edit: Talking to my co-worker while I type (I'm not being serious in this discussion)...

Him: "But he'd still lose his edits of the day."

Me: "Well d'oh, he should've checked them in beforehand."

{Pause}

Me: "You could edit your Makefile to do it for you."

Him: "Now that would be strange. You usually check in after they compiled successfully."

Me: "If they don't compile, the edits were crap anyway."

{He laughed hard at that point and asked me to add this discussion to the post. )

@AJ
I was unaware of Solar's makefile tutorial you linked to. It's pretty interesting, maybe I can integrate a few of his features into my own setup. I really like the idea of setting up testing from within the makefile. His page somewhat nullifies what I have posted here, I guessed I could have just googled for a makefile, instead of writing my own

@Solar
Version control would probably be a good idea as well. You raise a good point in bad changes being checked in, but I could just write a separate make target to do it, such as "make checkin" or something like that. If I do, I could post those changes here perhaps...

For highly localized requirements (i.e., only one person on one machine working on something consisting of only a few files), RCS is completely sufficient - it allows you to keep version histories of individual files, but very little more. I tend to keep central configuration files of my system under RCS control (/usr/src/linux/.config, for example).

For anything beyond that, I'd suggest Subversion - not because it's so powerful, but because it's Good Enough (tm) and so widely used that it's very easy to get support if things go wrong.

Checking in your files automatically was a joke. Don't do that. Deciding when and what to check in is central to a good development process. You check things in when you got to the next somewhat "stable" point you could describe with a single sentence. No sooner, no later. (IMHO.) And you don't need Makefile help for that, as every VCS system (well, perhaps not RCS) already supports you well enough.

Solar wrote:For anything beyond that, I'd suggest Subversion - not because it's so powerful, but because it's Good Enough (tm) and so widely used that it's very easy to get support if things go wrong.

I'd recommend GIT for that - you don't need a server to use it, and it's really, really fast.

Hi,

samoz wrote:Version control would probably be a good idea as well. You raise a good point in bad changes being checked in, but I could just write a separate make target to do it, such as "make checkin" or something like that. If I do, I could post those changes here perhaps...

I saw a video from the coreboot project a few weeks ago, partly about their source code management. If I remember it right, every time someone commits code it builds the new version for a variety of target machines, installs the new binaries onto the ROMs of some slave machines, boots those slave machines and runs some quality assurance testing and gets the results from the slave machines. It seems they were planning to make it so that it's impossible to commit any code that breaks any target machine, but found that it slowed down development too much because the testing took half an hour or more, so they allow the commit and generate reports so they know which commit broke what. They're also using some relatively cool hardware to do this - all remote control via. USB, including updating the firmware/flash on the slaves and controlling the power supplies.

I go the opposite way - if I'm too lazy to figure out how to use some sort of version control utility, then I'll definitely be too lazy to attempt to port some sort of version control utility to my OS in the future. I use NASM, a text editor and a utility I wrote myself - all relatively easy to port to some strange OS that isn't anything like Unix...


Cheers,

Brendan

I have worked in such an environment for several years. Every "ticket" was done in its own branch, and before such a branch was merged back into HEAD, a full test suite was run which would deny the merge if the quality score dropped. Testing an individual unit took a couple of minutes, the full test suite took several hours, but it didn't block any of the other branches.

That was comfortable working, because you could be confident your change didn't break things.

Solar wrote:I have worked in such an environment for several years. Every "ticket" was done in its own branch, and before such a branch was merged back into HEAD, a full test suite was run which would deny the merge if the quality score dropped. Testing an individual unit took a couple of minutes, the full test suite took several hours, but it didn't block any of the other branches.

That was comfortable working, because you could be confident your change didn't break things.

Agreed, this was how my previous employer ran things. Along with the automated testing, you had to get your code reviewed by both a technical reviewer (a peer) and "final reviewer", whose job it was to check that you'd set all the correct automatic test suites off, etc.

It worked really well.

In other news, Transitive ltd (the previous employer I spoke of, who had offered me a job should they be recruiting after I graduate from University) have just been bought out by IBM. Which puts my job offer in a slightly different light - It may now be completely invalid

I've reconfigured my makefile to provide an interface to allow testing and automated version control.

Now I can simply type "make start" (to checkout & sync), "make test" (pretty obvious), and "make finish" (to check everything in). I use Perforce for version control, because I got very familiar at my last job, and I really like using it. It's meant for a graphical interface however, as the command line is very clunky. Instead, I wrote my "make start" and "make finish" targets to automate the entire process.

The company I worked for always had nightly test suites (8+ hours) and each developer did smaller test suites (5-10) minutes before a piece of code was checked in. If any of the test suites showed failures where there used to be passes, the changes were rejected. I learned to love and hate regression testing.

Actually there are build mangers and build engineers for building a large software project , right ? Or am i asking a stupid question or what

In other news, Transitive ltd (the previous employer I spoke of, who had offered me a job should they be recruiting after I graduate from University) have just been bought out by IBM. Which puts my job offer in a slightly different light - It may now be completely invalid

Its shouldn't really be a problem if you have an offer letter already with you . But IBM has a bad reputation of screwing employess , at least here in India .

Regards
Thomas

Shrek wrote:Actually there are build mangers and build engineers for building a large software project , right ? Or am i asking a stupid question or what

I have yet to meet one.

Solar wrote:

Shrek wrote:Actually there are build mangers and build engineers for building a large software project , right ? Or am i asking a stupid question or what

I have yet to meet one.

Myself also - normally other engineers are seconded to the role. In my company some engineers were also "technical authorities" - they were given a package as their own and could review all commits that touched it. One such package was the "environment" package, which included the build system.

We did however have a team of "gatekeepers", who managed the Perl scripts and servers used to do the automated testing...

As far as the job goes, I never got a formal offer letter. It was an informal offer that was conditional on the company being in a position to employ me (i.e. not already laying off staff!)

James

HI ,
I can introduce you guys to a team of build engineers if you come to my place . I am however not one .Our source code base is so huge that, maintianing it requires a few good engineers.

Regards
Thomas