Nerd Tonic: Build Procedures

A "simple" build procedure could be defined thusly:

Here are some reasons to use the simple build:

A build procedure requiring more than one or two steps is error-prone.
When building-to-release, there are no second chances.
Any changes to the build procedure upsets (N minus 1) developers, where N=number of developers and 1=the developer making the change. You can't meaningfully change a one step procedure very easily.

What do you do when there are multiple clients receiving your software, and each receives a slightly different version? For example,

Client 1 receives a reentrant version of your software, delivered with selected source code files.
Client 2 receives your software as a non-reentrant fully-compiled lib.a and header files.
Client 3 receives your software as a lib.so and header files for linux.
Client 4 receives your software as a DLL for Windows.
Client 5 receives your software with certain capabilities disabled.
...

When there are tens of clients, what is the best approach towards maintaining a simple release procedure? Here's my best guess:

Maintain (under revision control, of course) a different make script (or makefile) for each client.
Have a top-level script that builds all customers' builds. This prevents a shared code change from inadvertently breaking the customer's build. It also delineates which releases will need regression testing.
Use labels/tags to specify when a customer's software is released. The problem I see here is that the tag database can get too large if you tag too frequently. A large number of tags can be tedious to browse. A good compromise is to use a convention for tagging that simplifies browsing.
Try to convince customers to move towards the ONE-TRUE-BUILD. It may save them money if they don't have to pay for the extra support that their own personal build requires. It saves the software company money because it decreases the quantity of code to maintain.

Nerd Tonic