Haiku compilation integrity (CVS question)

1

Yesterday, I checked out all of the current source for Haiku and the kernel did not successfully build. I just wanted to be able to create a kernel image and run it in Bochs before digging into the code more. I understand that there is a precompiled set of binaries out there that I could just extract and it contains a kernel that I could run to just see what I was interested in for the first step. But, in general, after a subsystem has gotten to the point of passing an initial basic unit test (e.g., basic unit test that nothing is broken to the point where you can no longer generate a binary library or executable), shouldn’t that be a precondition before checking in any modified source?

To put it another way, is there a way in CVS for the maintainers of each kit to be able to create development version snapshots that are at least guaranteed to compile with the noted exception that any changes past that freeze are not necessarily going to compile? That is, if I check out a source “snapshot”, the kit will at least compile but if I check out “current”, all bets are off.

How does the Linux development effort, all of the large GNU projects, etc. handle a distributed development life and at least have current builds able to pass a simple compilation phase more times than not?

Even though I know nothing of the Haiku from an internal perspective yet, shouldn’t it be easy for any new developer to pull down the source and, at a minimum, request from CVS the exact version of sources that built the binaries from the one available in the download section?

Thanks,

Steve

2

Haiku is still under heavy development and revision. Things change all the time. While it would certainly be possible to make snapshots, I think it is rather useless at this point.

Personally, I would prefer that people don’t check in things that don’t compile – or double-check that they didn’t forget to commit certain files.

Sometimes it is differences in build environments will cause things to break (not everyone uses the same version of BeOS or the compiler).

Once we reach R1, I agree that we should come up with a set of rules for this, but now it’s way too soon. That’s just what life on the bleeding edge is like. :wink:

3

I guess that if you’re in the newbie boat (like me) that it’s more of a waiting game for the checkins to align just right or R1. That’s fine. I’ll just read the code for now.

Thanks and continued success in these early development stages. The work already done is impressive. I would go so far as to say that once a reasonable stability is in place, many Linux hobbyists will flock over to take on some porting challenges…just for the fun of it.