Review Request: Build-infra M1

[David Holmes]

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