Re: [BuildStream] Proposed removal of `workspace reset --soft`

[Darius Makovsky <darius makovsky codethink co uk>]

Thanks Jürg,

On 19/11/2019 17:46, Jürg Billeter wrote:
> Hi Darius,
>
>
> On Tue, 2019-11-19 at 17:19 +0000, Darius Makovsky via buildstream-list 
> wrote:
> > [...]
> >
> > [...]
>
> For autotools projects, rerunning `./configure` before `make` may
> trigger a full rebuild, if I remember correctly. It's also fairly slow,
> even more so if autogen/autoreconf is called as well. I.e., to support
> (fast) incremental builds with such build systems, we must avoid
> calling the configure commands unless they have failed before.

Yes, that's sensible. The limitation at the moment is that this
configure command is not reflected into the local workspace since
workspaces are now handled by the source plugin. This is related to what
I was mentioning about plans for supporting incremental remote-execution
builds; We will need to save more information in the workspace config so
that there is a mapping from the local workspace state and the
configured workspace state so that we can accurately retrieve the
buildtree. However I think the question still remains whether we could
accurately say that the workspace is prepared if the local-state key has
changed. I think what you're suggesting is that the onus should be on
the user to correctly soft-reset any workspaces that need to be
reconfigured. That's acceptable but I think this should be made more
explicit to a user. Perhaps an INFO or WARN that it's reusing a cached
result. This also means that we will need to save the previous local key
in the workspace config also. That will eventually be required for
incremental support anyway though.

> [...]
>
> That said, with the separation of workspace (source) directory and
> buildtree, BuildStream can also easily trigger a full rebuild. It may
> make sense to change the soft reset function to trigger a full rebuild
> by clearing both the reference to the last build and the prepared flag.

That seems sensible but I'm not sure it's necessary in a
post-incremental support world.

-- 
Best Regards,
Darius


For Codethink's privacy-policy please see
https://www.codethink.co.uk/privacy.html