Re: [BuildStream] cache key changes

[Jürg Billeter <j bitron ch>]

Hi Darius,

Thanks for writing this up.

On Fri, 2019-07-05 at 15:00 +0100, Darius Makovsky via buildstream-list 
wrote:
> [...]
> * `dependencies` is replaced by:
>     - `dependencies-strong` (containing the strong cache keys of
> dependencies)
>     - `dependencies-weak` (containing the weak keys of dependencies)

Weak cache key dicts normally only contain the names of the
dependencies, not their (weak) cache keys, otherwise the cache key of
an element would change whenever the source of a dependency changes,
which we want to avoid for non-strict builds.

`dependencies` can currently have three different formats:

1) To calculate strict cache keys: `dependencies` contains the strict
cache keys of all build dependencies and their runtime dependencies.

2) To calculate weak cache keys for elements that don't set
BST_STRICT_REBUILD: `dependencies` contains the names of all direct
build dependencies.

3) To calculate weak cache keys for elements that set
BST_STRICT_REBUILD: `dependencies` willcontains the weak cache keys of
all build dependencies and their runtime depdnencies.

Could it make sense to use 'dependency-keys' for (1) and (3), and
'dependency-names' for (2)? Or shall we use three different key names:
'dependency-strong-keys', 'dependency-names', 'dependency-weak-keys'?

> * `context` is removed
> * `project` is removed

To clarify, they are always empty and thus, they don't serve any
purpose.

> * `environment` is replaced `environment-variables`

The .bst format also uses `environment` for this. I'm not convinced
we're reducing confusion by using different names in .bst and the cache
key dict.

> [...] In addition it is proposed to insert `public-nocache` into the
> dictionary. Values which are publically defined but not affecting the
> build result constitute the values of `public-nocache`.

`public-nocache` would be an addition to the .bst format. Its purpose
would be to support public data that does not affect the cache key
(similar to `environment-nocache`) and thus, `public-nocache` would
never be added to the cache key dict.

I think it would be best to discuss this separately as it would be a
format enhancement and would not affect the cache key. That discussion
should include a description of possible use case(s) for `public-
nocache`.

Cheers,
Jürg