gst-plugins-good: fix typo BR2_TOOLCHAIN_HAS_THREAD

Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

---
 package/gstreamer/gst-plugins-good/Config.in |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Note: I don't understand why kconfig does not check/warn on this...

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

 > Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>

Committed, thanks.

Hello Yann,

On Thu, 19 Dec 2013 22:02:23 +0100, Thomas De Schampheleire wrote:

>  comment "souphttpsrc needs a toolchain w/ wchar, threads"
> -	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREAD
> +	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS

Do you know if there is a way of making kconfig complain loudly if
there is a reference to an undefined symbol?

I know of only one occurrence in Buildroot where we rely on a
non-existing symbol: BR2_BROKEN. But we could just as well define this
symbol to be always false.

Having such a check would help ensuring we don't make typos on symbol
names.

Thanks!

Thomas

Thomas, All,

On 2013-12-20 09:50 +0100, Thomas Petazzoni spake thusly:
> On Thu, 19 Dec 2013 22:02:23 +0100, Thomas De Schampheleire wrote:
> 
> >  comment "souphttpsrc needs a toolchain w/ wchar, threads"
> > -	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREAD
> > +	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
> 
> Do you know if there is a way of making kconfig complain loudly if
> there is a reference to an undefined symbol?

No, this is not even a warning.

When Kconfig parsess a 'depends on' line, if the symbol does not exist
yet, it is added to the list of symbols, in case it is defined later on.

But then there is no way to know if a symbol was added because there was
a corresponding 'config' (or 'menuconfig' or 'choice') entry in any of
the Config.in files, or because it was added due to it being listed in a
'depends on' (or a 'select').

We can't even rely on the symbol having no type, since it is valid for a
symbol to have no type (can't recall off-the-top-of-my-head what case it
was, but it is valid in the Kconfig grammar).

Regards,
Yann E. MORIN.

Dear Yann E. MORIN,

On Fri, 20 Dec 2013 23:45:57 +0100, Yann E. MORIN wrote:

> > Do you know if there is a way of making kconfig complain loudly if
> > there is a reference to an undefined symbol?
> 
> No, this is not even a warning.
> 
> When Kconfig parsess a 'depends on' line, if the symbol does not exist
> yet, it is added to the list of symbols, in case it is defined later
> on.

Ok.

> But then there is no way to know if a symbol was added because there
> was a corresponding 'config' (or 'menuconfig' or 'choice') entry in
> any of the Config.in files, or because it was added due to it being
> listed in a 'depends on' (or a 'select').

Can't we add this information? When you find a symbol, if it's through
a depends on or a select, you store the symbol, but mark it as
"referenced". When you find a symbol that is really defined through
config/menuconfig/choice, you store the symbol and mark it as
"defined" (or changed from "referenced" to "defined" if the symbol had
already been found). And then, at the end of the parsing, if there are
some remaining symbols marked "referenced", whose state has not been
changed to "defined", you warn about them.

Am I dreaming too much about kconfig ? :-)

Thanks!

Thomas

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 > Can't we add this information? When you find a symbol, if it's through
 > a depends on or a select, you store the symbol, but mark it as
 > "referenced". When you find a symbol that is really defined through
 > config/menuconfig/choice, you store the symbol and mark it as
 > "defined" (or changed from "referenced" to "defined" if the symbol had
 > already been found). And then, at the end of the parsing, if there are
 > some remaining symbols marked "referenced", whose state has not been
 > changed to "defined", you warn about them.

I was thinking something like that as well. We might not be able to tell
the user where the symbol was referenced, but we can atleast warn that
it wasn't found.