There seems to be a problem with the cooperation between lv_conf_internal.h and Kconfig.
For example, when the LV_BUILD_EXAMPLES function is turned off in menuconfig,#define CONFIG_LV_BUILD_EXAMPLES 0 will not be written in config.h, resulting in that LV_BUILD_EXAMPLES cannot be disabled.

When boolean symbols are defined to n the symbol is not "defined", so I think the value in line 1527 should be changed from 1 to 0.

When boolean symbols are defined to n the symbol is not "defined", so I think the value in line 1527 should be changed from 1 to 0.

There are many options that have this problem, such as LV_USE_FLEX which is enabled by default in undefined.

I haven't been able to take a look into the additions to the Kconfig, maybe they are enabled by default.

Does it mean we should disable everything by default? Including all the widgets and features?

I remember we followed the default configuration (the one in lv_conf_temp.h), but it was a while ago.

Ah, so it the Kconfig and lv_conf_template.h are in sync the problem is solved.

Using LV_CONF_MINIMAL might alter the default values of Kconfig though.

E.g. with LV_CONF_MINIMAL 1 LV_USE_ASSERT_NULL will be always enabled.

 config LV_USE_ASSERT_NULL
      bool "Check if the parameter is NULL. (Very fast, recommended)"
      default y if !LV_CONF_MINIMAL

#ifndef LV_USE_ASSERT_NULL
#  ifdef CONFIG_LV_USE_ASSERT_NULL
#    define LV_USE_ASSERT_NULL CONFIG_LV_USE_ASSERT_NULL
#  else
#    define  LV_USE_ASSERT_NULL          1   /*Check if the parameter is NULL. (Very fast, recommended)*/
#  endif
#endif

I wonder if we should alter the logic in lv_conf_internal.h. We can simply detect if there is a Kconfig environment or not:

#ifdef CONFIG_LV_COLOR_DEPTH
#  define LV_KCNFIG_PRESENT
#endif 

And with the configs:

#ifndef LV_USE_ASSERT_NULL                /*Do not overwrite externally set defines*/
#  ifdef LV_KCNFIG_PRESENT                /*Use the value from Kcfonfig if present*/
#    ifdef CONFIG_LV_USE_ASSERT_NULL
#      define LV_USE_ASSERT_NULL CONFIG_LV_USE_ASSERT_NULL
#    else
#      define LV_USE_ASSERT_NULL 0        /*If a config is not defined then should be evaluated as 0*/
#    endif
#  else                                   /*Without Kconfig set the default value*/
#    define  LV_USE_ASSERT_NULL          1   
#  endif
#endif

What do you think?

I think the logic in the configuration files will become huge. Maybe we should use the lv_conf_kconfig.h file, see how we're defining the CONFIG_LV_BIDI_BASE_DIR_DEF symbol.

Maybe we can add something like this in lv_conf_kconfig.h. The LV_BUILD_EXAMPLES value is 1 by default in lv_conf_template.h (see here).

#ifndef LV_BUILD_EXAMPLES
#ifdef CONFIG_LV_BUILD_EXAMPLES           // Default value, used when LV_BUILD_EXAMPLES is enabled in the Kconfig
#define LV_BUILD_EXAMPLES_DEFAULT 1
#else
#define LV_BUILD_EXAMPLES_DEFAULT 0    // Value used if we disable LV_BUILD_EXAMPLES in Kconfig
#endif
#endif

Then in lv_conf_internal.h:

#ifndef LV_BUILD_EXAMPLES
#define LV_BUILD_EXAMPLES LV_BUILD_EXAMPLES_DEFAULT
#endif

Does it makes sense?

I think the logic in the configuration files will become huge.

IMO it doesn't matter much. It's a long, boring, repetitive file which is generated by a script. Not intended to read/edited by humans. (Although it's quite readable)

Maybe we can add something like this in lv_conf_kconfig.h.

lv_conf_internal.h is autogenerated and we can't/shouldn't pick 1-2 configs that are treated differently. I'd rather go with a longer but generic lv_conf_internal.h instead of adding minor tweaks here and there.

If you agree I can update the script to see how it works.

lv_conf_internal.h is autogenerated and we can't/shouldn't pick 1-2 configs that are treated differently. I'd rather go with a longer but generic lv_conf_internal.h instead of adding minor tweaks here and there.

I totally forgot that lv_conf_internal.h is generated by script.

If you agree I can update the script to see how it works.

Are you thinking of updating the script just for those options (LV_BUILD_EXAMPLES, LV_USE_FLEX) or for all?

Are you thinking of updating the script just for those options (LV_BUILD_EXAMPLES, LV_USE_FLEX) or for all?

For all. This seems like a more robust value checking for all options

#ifndef LV_USE_ASSERT_NULL                /*Do not overwrite externally set defines*/
#  ifdef LV_KCONFIG_PRESENT                /*Use the value from Kcfonfig if present*/
#    ifdef CONFIG_LV_USE_ASSERT_NULL
#      define LV_USE_ASSERT_NULL CONFIG_LV_USE_ASSERT_NULL
#    else
#      define LV_USE_ASSERT_NULL 0        /*If a config is not defined should be evaluated as 0*/
#    endif
#  else                                   /*Without Kconfig set the default value*/
#    define  LV_USE_ASSERT_NULL          1   
#  endif
#endif

There's a case that I think we're not considering, configure LVGL with lv_conf.h in platforms that support Kconfig. So instead of LV_KCONFIG_PRESENT should we name it LV_USE_KCONFIG?

There's a case that I think we're not considering, configure LVGL with lv_conf.h in platforms that support Kconfig.

If the value is set in lv_conf.h the first #ifndef will skip the whole block and leave the set value.

If you say ok, I can add the proposed changes.

@kisvegabor
Can this pr be merged? If LV_BUILD_EXAMPLES can be disabled, the compilation time can be reduced.

I'm waiting for feedback on this: #2555 (comment)

I've pushed the changes proposed here.

I needed to revert it due to some unexpected issues. I will investigate tomorrow.

@xiaoxiang781216 has suggested to change bools to int with 0/1 possible values.

I'm ok with this but comments from Kconfig users would be great.

We are about releasing v8.1 and it'd great to fix this issue for it.

If there is no objection for "change bools to int with 0/1 possible values" can someone who uses Kconfig contribute with this update?

We are about releasing v8.1 and it'd great to fix this issue for it.

I can fix this issue.

If there is no objection for "change bools to int with 0/1 possible values" can someone who uses Kconfig contribute with this update?

It has a bad side effect, here is the screen shot when LV_BUILD_EXAMPLES is bool:

here is the screen shot when LV_BUILD_EXAMPLES is integer:

The square(blank/cross) become a circle(0/1) at the begin, more bad effect is that we have to change the value in popup window instead with space key directly:

Another fix is change all default bool config to false.

Which propose do you like?

Thanks for looking into this. Using this pattern could be an option too. My first attempt to implement it failed because it can be applied only to config options with numeric type. But of course we can treat non-numbers and numbers differently.

As an experiment I updated lv_conf_internal_gen.py to add a more complex check if the default value is 1.

I merge it to see if there are any unexpected problems before the release.