Common Build Environment

The opposite of the situation where each developer has different libraries, build tools, and compile scripts on their workstation.

Let's start a list of BestPractices. All these items are under the caveat "modulo whatever obvious circumstance prevents them..."

All KnowledgeWorkers? keep the project's source on the same drive letter (mounted as Z:\, or ~/src, for example), and they keep the source in a tree with the same folder names under that drive.
No build scripts should ever rely on the absolute path of the source/project files. Such things will always change - in which case you'll want to know that your scripts don't have any hardcoded paths. KeepItSimpleStupid (i.e. use relative paths and don't care where the sources are put)

Notice the first two bullet points do not contradict each other. Any more?

I suspect some teams never have trouble here, while others make bad decisions early and pollute their environments in ways that are hard to reverse.

All of the tools (compilers, etc.) required to transform the project source code into a running application are available to all developers. The version (or acceptable range of versions) of these tools used is defined. Attempts to build the project with a different version are detected.
No build script contains machine names. Host names in build scripts are an AntiPattern that indicates your project will be in danger when "The Build Machine" fails or has its configuration changed in some subtle way. Exception: localhost
- Alternately, only allow machine aliases. For instance, put the word "dbserv" in your build scripts, but make "dbserv" an alias to your database server, real name "fatdisk". When fatdisk dies, move the dbserv alias to "fatdisk2", which serves a back-up database. Use DNS (or your other naming scheme)
- Or arrange so the machine names are replaceable variables. Demonstrate it works by making an alternate build machine.