On Fri, 08 Jun 2007 04:17:44 +0200
Roland Mainz <[EMAIL PROTECTED]> wrote:
[...]
> Uhm... I strongly disagree in this case... I belive that it's better to
> make sure that the tree (even this prototype tree) builds all the time
> after doing commits with no exception. Otherwise other people like April
> who use the tree can't continue their work until I have cleaned-up the
> mess I caused...
[...]
I'm not sure how you organize your work, but one way to do this would
be have two trees. One you work in and do some local compiles. The
other you do nightlies in (its a child of the first). As soon as you
pull (hopefully zfs clone) the second tree spin a incremental nightly
in it (nice it down if it makes work on the other tree too painful).
Work away in the first tree doing fairly narrow compiles. At some
point you want to do a full build. kill the build in the other tree if
its not done. pull over the changes. Restart an incremental nightly.
The idea is to get as much parallelism between your build and
development process as possible so you are not waiting for the full
build to grind through a lot of source you will never touch. You might
also turn off non-debug builds, gcc compilation, lint (although I
suggest you continue to lint the code you are working on), or other
like things (see nightly(1) for ideas). Just remember that when you
reach final approach you *must* turn those back on. And there is risk
that something you would have learned earlier will then rear its ugly
head.
Or maybe you already do all of this. I do this even when the build
machines can spin a full build in under 4 hours. I just hate waiting
to get the result from my primary project when most of the work getting
there involves a bunch of stuff which isn't directly related to my
change.
And if you have any fears about the full build failing then keep a
close look at the logfile. Nothing like spinning a full build on a
slow machine, hitting the gym, and getting back to see it probably
failed before you were out of the front door. When I first graduated
from college I worked on a program that took about 30 minutes to build
(assuming only a few files changed) and 30 minutes to download to the
target. We were *really* careful about testing code before it was put
into the build gate and we squeezed everything we could get out of a
target run. Fortunately it was a simple processor so writting code
bursts to do simple things and trying them out really wasn't all that
painful. A similar focus might help you.
mph
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
