re: Project options and other format enhancements (and dropping "variants")

[Angelos Evripiotis <angelos evripiotis gmail com>]

Hi!

This plan looks like it nicely addresses some concerns that I had, which you
listed:

    * Combinatorial explosion of variants needed to express multiple options,
      e.g. with{,out}_poll__with{,out}_sqlite__with{,out}_readline__with{,out}_gdbm
      etc.

    * Global selection of variant options from the CLI, e.g. 'enable all
      asserts everywhere', 'build everything without optimisation', etc.

I don't think it addresses these ones I also have:

(1) Building particular elements for debugging

i.e. while keeping the rest optimised. In the options world, I think this means
changing some options selectively from the command-line. Perhaps something like
this would be workable: 'bst build app1.bst --option mylib.bst:debug=true'.

(2) Allowing elements to specify what they need from their dependencies

This is so that we can easily tailor to the needs of each pipeline within a
project. This worked wonderfully with variants, I think the problem was that
each variant was mutually exclusive.

Might we be able to use options in 'depends' declarations in a similar way?
e.g.:

    app1.bst:
        ...
        depends:
            - filename: foo.bst
            options: flying-ponies
        ...

    app2.bst:
        ...
        depends:
            - filename: foo.bst
            options: dancing-badgers
        ...

Assuming that we can supply both flying ponies and dancing badgers then this
would be ok. If we can't then I imagine we can use the '!!' operator to
complain about this in 'foo.bst'.

Perhaps there could be namespacing to separate global options and element
options, to avoid collision and confusion. I haven't thought that through yet.

One use-case I'm considering for this is dealing with breaking changes across
versions of a library. If you imagine a project with 1000's of flatpak-like
things being generated from BuildStream, from separate pipelines, it could be
tricky to get all of them to be ok with a breaking change in the same commit.

Potentially we could use a 'version' option on an element to allow elements
that depend on the library to require the older or newer version. If two
versions are requested in a pipeline, we can generate an error thanks to the
'!!' operator.

What do you think?

Cheers,
Angelos