Re: What Problem does BuildStream Resolve ?

[Paul Sherwood <paul sherwood codethink co uk>]

Hi Edmund,

we should maybe take the generic discussion to a different list, and 
return here once we've got our story straight :-)

But anyway...

On 2018-01-25 14:00, edmund sutcliffe+buildstream codethink com wrote:
> So..
>     I'm unsure if this answers my question.
>
>    Builds of what take too long ? An individual software piece or the
> aggregation of software ?

Builds of individual components and of aggregations are widely perceived 
to take too long, because engineers typically have to wait and are less 
productive while the builds are happening.

I'm waiting for BuildStream folks to comment on whether this is a core 
problem that BuildStream is designed for and cares about.

>    Given that buildstream consumes other build systems. how is that
> helping with build tools misbehaving ?

I didn't say that it is. I've asked the question :)

However:

- arguably by declaring all inputs, we can constrain the operation and 
environment of build systems which are consumed, thus reducing the 
potential for misbehaviour.

>    Are you arguing that the ability to build isolated environments to
> construct software builds reproducible software ? I'm fairly sure I
> can provide evidence that it will not provide binary identical
> software.. So where is this value ?

I'm not arguing, I'm asking. However:

- I and colleagues have some years' experience (originally with other 
tools, then with Baserock, now BuildStream) of controlling the inputs 
and environment for builds, with the working assumption that this 
control will lead to 'functional reproducibility' even if the binaries 
are not bit-for-bit. That working assumption has proved to be valid for 
all of the production implementations i've been involved in so far.

br
Paul