All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PROPOSAL] Package feature switches, redux.
Date: Tue, 12 Jul 2011 12:03:26 -0500	[thread overview]
Message-ID: <4E1C7E5E.5020001@windriver.com> (raw)
In-Reply-To: <4E11EDD1.1000308@slimlogic.co.uk>

On 7/4/11 11:44 AM, Graeme Gregory wrote:
> On 07/04/2011 05:12 PM, Chris Elston wrote:
>>> Hi, with my Angstrom cap on I like this syntax and I think it will be
>>> really useful.
>>>
>>> A second level concern I have is about conflicting features, its not
>>> something we will come across probably in DISTRO land as we are sensible
>>> enough not to select them. But users could select them in local.conf.
>>>
>>> Graeme
>> As a new developer, I've discovered that there are plenty of things that
>> you can set in local.conf which break things :D
>>
>> Could you please give an example of conflicting features that could
>> cause problems, I'm not experienced enough with OE to have encountered
>> that problem yet.
>>
>>
> Cant think of a solid one off the top of my head, but I mean the cases where
> 
> --enable-feature means that --disable-another-feature is done.
> 
> This is why I listed it as a secondary issue.

I remember seeing similar issues as well.

I really like this syntax described for the options.  If there is some way to
list a conflicting option -- or even simple some python syntax useful within a
recipe itself to say "hey you can't specify these two things and use this
recipe", that would be all that I think is needed.

I rarely find packages where it's likely someone will try to configure a
conflicting option set, but it does happen.. if we find it.. we should be able
to note it within the recipe and have it flag the user before do_configure is
run.  (Preferably even before that!)

--Mark

> Graeme
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




      parent reply	other threads:[~2011-07-12 17:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-04 11:54 [PROPOSAL] Package feature switches, redux Chris Elston
2011-07-04 13:58 ` Richard Purdie
2011-07-06 18:15   ` Chris Elston
2011-07-04 15:43 ` Graeme Gregory
2011-07-04 16:12   ` Chris Elston
2011-07-04 16:44     ` Graeme Gregory
2011-07-04 16:49       ` Chris Elston
2011-07-18 21:20         ` Martin Jansa
2011-07-12 17:03       ` Mark Hatle [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E1C7E5E.5020001@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.