Kelly,
On 24/03/2012 1:16 AM, Kelly O'Hair wrote:
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.
I don't know what exactly you mean by that but I don't propose that multiple
developers update anything. I expect multiple developers to _use_ a stable
(perhaps local) copy of the build tools for the build they are doing. How
that one copy gets setup is a different issue.
David
-----
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
