Discussion: Some type of flag(s) to conditionally build/not build support
Richard Purdie
richard.purdie at linuxfoundation.org
Tue Apr 5 12:27:53 UTC 2011
On Thu, 2011-03-31 at 21:04 +0100, Richard Purdie wrote:
> The various components I suspect we need here are:
>
> a) A mechanism to denote there is a choice of configuration for a recipe
> and what the implications of the configuration choice(s) are (i.e.
> additional DEPENDS)
>
> b) A mechanism to select those configuration choices. This is policy
> configuration so it should be done at the distro level and have the
> implications of changing it clearly spelt out for the user.
[...]
> This leaves a) and b) as the tricky parts. I have some ideas about that
> but I'll save those for a follow up email as there are things to think
> about here so far...
The thread has gone quiet again. Let me therefore suggest something
which I don't really like that much and see what people think. I just
worry that in the absence of a better idea, this might get adopted and
I'm not conviced this is in the best interested of OE and it may cause
scalability and testing/reproducibility issues.
For a), we could do something using our existing syntax relatively
easily:
CONFOPTIONS += "theora"
CONFOPTDEPENDS_theora = "theora"
CONFOPTENABLE_theora = "--enable-theora"
CONFOPTDISABLE_theora = "--disable-theora"
The core code would then compare CONFOPTIONS with something like
DISTRO_FEATURES and then only enable the options that matched, appending
the appropriate ENABLE/DISABLE options to EXTRA_OECONF and mangling
DEPENDS as appropriate.
The drawback is some added anonymous python processing but I think that
is inevitable.
The other thing this will do which I've always feared is trigger users
to add 1001 different CONFOPTIONs to recipes, likely we'll end up with
one per possible config options as someone, somewhere will want to turn
any dial available.
Namespace in DISTRO_FEATURES is going to become very hard to police and
is going to become a crazy long list of keywords. The exact meaning of a
given key will also likely become unclear.
There is also a question of MACHINE_FEATURES and should given machines
be allowed to disable flags for a given hardware platform? I think this
kind of policy is likely best limited to per distro, not per machine but
I suspect others will want that additional customisation (not to build
anything video if their machine has no graphics support).
On the small plus side, the checksum code should be able to give us a
clue what the user configured something with. We could also checksum
EXTRA_OECONF specifically and append it to PR to make it really clear
although I'm relcutant to add yet more random checksums. This is one
case it might be justified in though.
Thoughts/Ideas/Comments/Flames?
Cheers,
Richard
More information about the tsc
mailing list