Discussion: Some type of flag(s) to conditionally build/not build support

[Koen Kooi]

Op 5 apr 2011, om 14:27 heeft Richard Purdie het volgende geschreven:

> 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?

We could start small and look at the current *FEATURES in .dev and -core and see how we can make them consistent or eliminate them with some clever recipe work. IIRC the big ones are the *libc features, enterprise distro and gplv3. After that we have little ones like PCI and madwifi.

regards,

Koen