Quick follow up...
> On Jul 30, 2020, at 7:27 PM, Douglas Winship
> <[email protected]> wrote:
>
[...]
>> Other than that, it's pretty verbose. I was envisioning something like:
>> build-depends:
>> - liba.bst
>> - compiler.bst [toolchain]
>> - platform.bst [platform]
>
> That would be a pretty useful format. It preserves the option of adding
> dependencies as a single line. (I'm assuming that multiple tags could be
> added on the same row, to one dependency.)
>
> It's much less powerful than having a dictionary though. A dict gives the
> plugin designer the flexibility to make config as complex or as simple as it
> needs to be.
I sympathize with the desire for one liner dependency declarations but don’t
find this particularly realistic or nearly powerful enough, also I favor
staying closer to YAML and avoiding additional custom value parsing.
[...]
>
> I like the idea of being able to group dependencies like this. In a large
> element declaration with a lot of dependencies, this could save a lot of time
> and space. There are some concerns though:
I would hope for this to be a separate thread if the conclusion is reached that
this is a good approach (I already favor this approach).
In terms of exact semantics I think we could just call this dependency
declaration style `dependencies` making it clearly separate from the other list
styles.
> If we want to give configure_dependencies() the ability to distinguish
> between the two formats, then would that be easy to implement? is it
> compatible with the data patterns that we currently use? If we don't want to,
> then will it be intuitive that these two different formats mean the same
> thing?
At implementation time this is trivial enough, all of these formats can be
normalized to provide the same inputs for instantiating the loader internal
`Dependency()` objects.
I think we need to keep all of these declaration styles valid for BuildStream 2
in order to ease transition, we might deprecate the older ones but I don’t
personally have strong feelings about this.
Cheers,
-Tristan
