Jump to content
XCOMUFO & Xenocide

The Build Plan


cyberdrift

Recommended Posts

Hi.

 

Sorry. Long day. Looks like we got some activity on Stewart's announcement of a build guy, so I thought I would try and talk a bit about it before going into the plan.

 

We have people working predominantly in Windows, but are trying to create a multi-platform product. The decision was made to use Standards like ANSI C++ and OpenGL with the expectation that they protect us and "do the right thing". And, with the understanding that the Standards are written with the necessary looseness needed to make them something that can be implemented, that will happen. What we will discover, however, is "the right thing" in Windows may not be the same "right thing" in Linux and that both will have a completely different view of "the right thing" than a completely different architecture like the Mac. Even if we step back to just developing for Windows, you have issues. Windows 9x is ANSI based, NT, 2K and XP is unicode, among other differences. DLLs with the same name are completely different for the different platforms (do a little research on ATL.DLL for the different versions of Windows, for example). Add on top of that that Service Packs, Office, Visual Studio and Internet Explorer all update core system components, making systems fundementally, and sometimes very suddenly, different from each other. Add all this up, and you get an idea why software development is littered with nonchalant shrugs and the frustrating comment "Works ok on my machine."'

 

So what do you do about it? Unfortunately, you have to set some rules. You have to call halts to developers progress. You have to take the time to demonstrate that the software has a basic level of sanity for all your targets. Its a long gunfight, and we're all going to have to stop and reload. If we do it all together, it can take of the eerie appearance of looking like we have a clue. Having set times where you have to match your changes with everyone else's changes and make sure it works on the platforms is important. Having mileposts where we know the overall functionality of the system, so that you can step back if necessary can save a project. This is how you can measure progress. This is how you can finally decide "its ready for release."

 

The idea of set time for the build is important. I am proposing 10 AM Sunday morning to lock down CVS. That would be my time (US Mountain Standard Time). I will get a translation of where that is to GMT, but I don't know it at the moment. If it isn't in CVS by lockdown time, it isn't in that build. Period. The goal of the build is to resolve whatever is happening and announce CVS open by Sunday night. If resolving issues means backing out a change, that will be decided and done. The news will be shared, and some work will have to be redone. Although I hardly encourage repeat offenses, the truth of the matter is you're not really writing code until you have single handedly killed a build. I will post a log of the build's steps and result. Particularly noteworthy errors may be enshrined in a Hall of Shame for all the see.

 

I have some experience with CVS and a group of developers. If people are not paying attention, multiple submissions to the same file can occur at roughly the same time. Please pay attention to the CVS tree when you check in a file. Look to see how many submissions have occured since the last build. Use Diff to see that the changes that are supposed to be there survive. Talking nicely to each other before the build can avoid a lot of unpleasant discussions between people after the build because someone's hard work got trampled.

 

Once the build is done and CVS is re-opened, all developers should completely refresh their base from CVS. If you have partially implemented code, it will be your responsibility to lay it over the new base after you have refreshed. This refresh step is just as important as the build step. It isn't going to do any good to prove sanity in the base one week, only to get clobbered next week because someone updated stale source and checked it in. Errors of this sort will be widely reported.

 

I have been talking to Gangsta, Red Knight and Stewart. We are in the process of defining how to perform builds with as many common processes for each platform as possible. We are shooting for a test run this weekend. As these are fleshed out, tools that will allow each developer to build the project the same way the build machines will build the project will be made available. What IDE or tools you personally use to develop code are yours. The criteria for code, however, will be its ability to integrate with the defined build process.

 

There will be some good builds. There will be some bad. I may never have to speak to some of you about build issues. Others might hear from me quite often. It frequently has nothing to do with your ability. It can have a lot to do with working on the edge, either personally or technology wise. We're all here for some sort of growth, I think. So let's take a deep breath and let the process begin.

Link to comment
Share on other sites

Add on top of that that Service Packs, Office, Visual Studio and Internet Explorer all update core system components, making systems fundementally, and sometimes very suddenly, different from each other.  Add all this up, and you get an idea why software development is littered with nonchalant shrugs and the frustrating comment "Works ok on my machine."'

I dont want to polute this thread, but cyberdrift has a point in here... do anyone remember that nasty bug with the mouse in the demo? Well that was caused (as someone report in here, cause i couldnt reproduce the error) by an inhability of W2K to acquire the mouse in an exclusive mode. So not every Operating System or even platforms are the same... Radeon Support comes to my mind right now... So i think that a standard Build Protocol like the one cyberdrift has explain is the best way to make things work. You have my vote on this issue.

 

Greetings

Red Knight

Link to comment
Share on other sites

ok I agree with the above. I also think each individual developer needs to be responsible too. The process for each CVS session I suggest is

 

update();

build();

 

if (error) correct();

 

code();

build();

 

if (error) correct();

 

loop:

 

commit();

update();

build();

 

if (error)

{

correct();

goto loop;

}

 

BTW the major points of this thread that we agree on should all be posted on the mailing list for those developers not currently active on the board.

Link to comment
Share on other sites

Guest stewart

Looks good, excellent as a matter of fact. Fortunately, this process has a way of revealing project tools use policies. If we miss something and errors keep occuring, it is noticed, dealt with, and procedures are defined or edited.

 

It --might-- not be nessessary for developers to update while they have files checked out, this will become appearant. However, once you have everything checked in and the build is declared good do a full get. As builds become more frequent (knock on wood) it may be adviseable to, if the build is good, do a full get right before your first checkout.

 

A couple things to note:

1) really there are 3 builds, not one, not all may break. There is a decision to make here in terms of policy (safety verses progress).

2) Before you check-in, if you change a file common to several executables/libraries/dlls, then you have to rebuild all of the effected items.

 

The times for builds must be an equal compromise between what is convenient for the build guy, and everyone else as a whole. However, if no one objects then away we go.

Link to comment
Share on other sites

well checkout you only do once unless you want to get the current full codebase again. you use update to update your system.

 

anyway, this is whenever you do an initial update you follow the above. you can logoff the net after that update and login whenever you do a commit. the proccess named code() there is when you write the actual new code and do builds inbetween maybe for days while you are at home. the build() after code is right before you commit does changes to CVS. after you commit those changes you should update and check out if the code on CVS still builds. if not you should fix it befor coding again.

Link to comment
Share on other sites

It sounds like we have overall agreement on this. Some of the details on how people keep their code bases current can be individual decisions. If every developer does it differently, but the end result is we have no checkins based on stale files, we're doing great.

 

I also think Gangsta's recommendations on building before submitting are good ideas as well. Now I'll get my tail in a chair and start doing some work on getting things set up for the build this weekend.

Link to comment
Share on other sites

×
×
  • Create New...