Project

General

Profile

Actions
Copy link

Bug #118

open

Kconfig defines symbols with unmet dependencies

Added by Nico Huber over 7 years ago. Updated about 7 years ago.

Status:
New
Priority:
Normal
Assignee:
Martin Roth
Category:
build system
Target version:
-
Start date:
05/18/2017
Due date:
% Done:

0%

Estimated time:
Affected versions:
Needs backport to:
Affected hardware:
Affected OS:

Description

Our current Kconfig setup, with the custom KCONFIG_NEGATIVES option, does not only output =n/=0 for unset booleans and numbers but also outputs booleans and numbers with unmet dependencies (i.e. symbols that are not defined at all for a given .config).

This makes Kconfig less predictable. So I ask, do we want this "feature" in the long run? For boolean symbols, we already have the IS_ENABLED() macro. For numbers, I'd argue that they are mostly used in code that should be guarded (preferably in the Makefile.inc).

OTOH, if we'd keep the current Kconfig behaviour, it would save us some ugly #if IS_ENABLED() guards (e.g. when CONFIG_* numbers are used in headers or shared code files).

Actions
Copy link
 #1

Updated by Nico Huber over 7 years ago

  • Category set to build system
Actions
Copy link
 #2

Updated by Stefan Reinauer over 7 years ago

  • Assignee set to Martin Roth
Actions
Copy link
 #3

Updated by Stefan Reinauer over 7 years ago

We should use standard Kconfig behavior going forward.

Actions
Copy link
 #4

Updated by Martin Roth about 7 years ago

I'll look at updating to the latest kconfig version from the kernel.

  • Update Kconfig documentation
  • Update Kconfig lint tool - #ifdef CONFIG_ will be valid again for bool values.
  • Test updates to see what additional changes to configurations this update causes.

Maybe this change should wait until after the October release so we can have a clean cut-off point.

Actions
Copy link

Also available in: Atom PDF