On Mar 22, 2012, at 4:51 PM, David Holmes wrote: > Not wanting to go too OT here but I see the build-deps server as something to > be used at most per machine rather than per developer. We have build servers > internally that can be used by dozens of developers and we don't want > multiple copies of toolsets. Even in the new build system I would expect to > see the toolsets (for cross-compilation) installed on shared NFS mounts for > use by these build servers. But at worse I would expect to have one > installation per machine.
Unless it is done properly, having multiple developers updating a single machine copy of build dependency files could be a disaster. Not all developers would be working on source bases with the exact same dependencies. And NFS mounts create even more complications, creating a network dependence and similar update issues. If you don't have control over these dependencies, every build you do could result in different bits, and if the build dependencies do need to change, it's important that the individual developer knows that they did change, and how to back it out or realize why things changed. It has been my view that local disk space is not an issue on most modern systems, and having many copies is not a problem if it is managed automatically and not manually, i.e. they really are the right copies. Having it local and unique to that developer would provide the most predictable results, but only if we can get the automatic install/update logic reliable. I'm currently having a great deal of problem with our internal build&test system and it's all related to the systems changing out from under us all the time. Automatic updates being installed, automatic virus definitions changing, automatic defragmentation of the disks every week, services that keep other services running, and automatic reboots for a variety of reasons. Virtual machines also come with mixed blessings, it's a complicated world. Stability and predictability is hard in an ever changing world. So I'm frequently trying to make sure that we are dealing with fewer variables and more constants, and if the constants need to change, change them carefully. -kto
