Semi Random Build Tips From Past Breakage
Contents:
General Strategies for Successful
Development
Compiler Quirks and Examples
General Strategies for Successful Development
Waterson's Hints.
1. Get a good build to work with. To do this, pull sometime during the
tree closure during morning verification builds.
2. Pay attention during tree closure. Follow n.p.m.builds and #mozilla
to see if there are spot fixes that get applied to get stuff working
during the tree closure. If _you_ can't build or run, then it's likely
that QA won't be able to either, and the tree will stay closed until
things get better. And, if you're to blame, all the better that you're
paying attention!
3. Don't update your entire tree to fix spot bustage. This'll just slow
you down. If something breaks in mozilla/foo/src, update mozilla/foo/src
_only_. There's a good chance somebody will have checked in a fix for
the bustage by the time you get to it. If it's still not fixed, update
mozilla/foo/public to see if it's some header bustage. Then scream
to
the newsgroups and on #mozilla.
3. Be smart before you check in.
a. Test your stuff. Write a test case if you're doing a new feature.
*Test* the test case if you're fixing a bug. Step through it in the
debugger to make sure your code does what you think it should do. Think
about what depends on you. See if you broke that stuff. Run it in
viewer. Run it in apprunner. Run mail. Run editor. Think about whether
or not this will have platform specific issues. Despite what QA says,
their smoke tests are marginally useful: I don't even think QA uses
them. (If they did, Sidebar wouldn't have been broken for a week :-/).
b. Be up-to-date. But don't get stressed out about being _exactly_ up
to
date, but be smart. Use a different level of paranoia depending on
whether you're updating one directory or ten, a header file, a C++
file,
a XUL file, a makefile. As a rule of thumb, update _at least_ the
immediate directories you're working in before you check in. If there
are changes in a directory, rebuild it to make sure you didn't hork
those dirs.
c. If you're adding or removing files, be sure that you've got Mac,
Windows, and Unix makefile changes ready to fly.
d. Don't check in if the tree has been burning for hours. Unless you
really feel like fixing bustage (see 4a, below).
4. Be smart after you check in.
a. Update your entire tree after you check in. Rebuild. If there's build
bustage, fix it. EVEN IF IT ISN'T YOURS. Make sure your build RUNS.
If
it doesn't, start to panic. Figure out what's wrong and who's to blame.
Make sure they know they're to blame.
b. Pull your changes on another platform. Rebuild. Test. Don't _have_
another platform? Go on #mozilla and find somebody who does.
c. Use the "Bonsai Query Page", "Tinderbox", n.p.m.builds,
n.p.m.checkins, and #mozilla to figure out who did what. Be sure that
_you_ contribute to the newsgroups and IRC when appropriate.
d. Use depend builds. On Win32, this requires some extra work ("nmake
-fclient.mak depend"), but is well worth it.
- egcs lets you define integer consts inside a class definition; VC5 won't, but you can use enum to do the same thing.
- Temporarily commented out (the unused) |construct| member which uses placement |new|, apparently not available on SunOS. That's the only bustage I see so far.
- Solaris is more picky than mac/linux/win32, i guess. I got bit the exact same way yesterday. The problem is that you have to include the definition of an interface before you ever use it in an nsCOMPtr, for the Solaris compiler.
- [warren@netscape.com - 09/11 12:45] So under VC6 you can assign a nsCOMPtr to a non-nsCOMPtr with no problem, but the other compilers are having problems. I've added a .get() where ever I introduced this to fix the problem, but I expect a few more red spots before everything picks up the change.