Saturday, April 29, 2006

Build flags declared bad for your health

Too many evils...

We keep getting bitten by this at work. We have several customers using the same codebase, with the only difference being how they are compiled. This isn't a case of one customer needing optimisation, and another not (we have that too). It's completely different code behaviours defined through build flags.

So, let me say it right now. Changing the behaviour of code through a compile time options and then shipping those variants to different customers is bad. Take that compile time option and make it run time. Otherwise, you can be sure that you will ship the wrong binary. We've done it so many times, it's becoming silly.

Your goal should be to have anyone check out, compile and ship your code to any customer using the same commands

There are several ways you can get rid of these options. My first preference is to get rid of it completely. Decide on a way the code will work and go with it. Why do you have the option at all? Is it faster in some way? Why isn't it good enough for all of your customers?

Next in order, I would get rid of the compile time flag completely and make it a run time configuration option. Make your system more configurable! You do have to be careful that you are providing something useful though. Why do you need to decide at all? Is it possible for the code to decide for you? (see previous post on configuration options).

Finally, if you absolutely must have a compile time option (for performance reasons or otherwise), build and ship all variants to all customers. Delay decisions as long as possible. It may take you another 2-3 hours to build both variants, but it will save you a round trip to your customer.

All of these will save you the embarrassment of yet again having your customer come back to you and say, "Don't you know how to compile your code?".

I hate hearing that question.

No comments: