Config.uk: Fix dependency issues & defaults

[andreittr]

Unless specifically required (like by app-sqlite) the main function should not be provided by default; lib-sqlite should also not be enabled by default if included (in line with other libs)
In addition, remove the hard select of UKMMAP and LIBNEWLIBC, allowing the use of posix-mmap & musl.

edit: Added new commit, renamed to be more descriptive of issues fixed

[mariasfiraiala]

Looks ok, thanks @andreittr!

Reviewed-by: Maria Sfiraiala maria.sfiraiala@gmail.com

[andreittr]

Updated w/ 1 new commit; please re-review, thanks!

[mariasfiraiala]

This works as expected. However it's a bit weird not having the library show up in the menu unless musl is selected.

Reviewed-by: Maria Sfiraiala maria.sfiraiala@gmail.com

[StefanJum]

@andreittr is there a way to have lib-sqlite depend on a libc but have it show up in the menufonfig anyway if no libc is selected?

I would use depends on as less as possible, since it's confusing to not have the library show up in the menuconfig, and since you don't always know the dependencies from the top of your head. It's frustrating to have to search for them, enable them and then select the library you want.

[andreittr]

@andreittr is there a way to have lib-sqlite depend on a libc but have it show up in the menufonfig anyway if no libc is selected?

I would use depends on as less as possible, since it's confusing to not have the library show up in the menuconfig, and since you don't always know the dependencies from the top of your head. It's frustrating to have to search for them, enable them and then select the library you want.

I see your point re: visibility of dependent config options; the one solution I see is to error out of the build process with an explicit check for HAVE_LIBC in Makefile.uk. At the moment this is used only in situations where expressing dependencies through Kconfig would cause a cycle, since it's pretty inconvenient for the user to find out they're missing dependencies at build time. Alternatively we could ask/set the config system to show hidden items, but that would make the config menu messy very quick.

Basically we have to decide which situation would inconvenience users less:
(1) not having a library show up in Kconfig unless a libc is selected (i.e., "invisible" dependency)
(2) having the library show up, but erroring out in build if a libc is not also selected (i.e., Kconfig allowing invalid configs, a bit at odds with its purpose, but not entirely a new problem)

[StefanJum]

Basically we have to decide which situation would inconvenience users less: (1) not having a library show up in Kconfig unless a libc is selected (i.e., "invisible" dependency) (2) having the library show up, but erroring out in build if a libc is not also selected (i.e., Kconfig allowing invalid configs, a bit at odds with its purpose, but not entirely a new problem)

100% agree. I would go for (2), as I personally would hate to add a library to the LIBS and have to search for all its dependencies in the source code for it to show up in the menuconfig.

Thoughts @mariasfiraiala @razvand ?

LE: We already use (2) in lib-compiler-rt)

[mariasfiraiala]

I'd also go with no. 2, just like @StefanJum suggested. Easier for both the users and us.

[andreittr]

LE: We already use (2) in lib-compiler-rt)

Fun fact: that example has been done precisely because lib-compiler-rt and libunwind (used to) have a circular dependency on eachother. The PR unikraft/lib-compiler-rt#14 halfway solves this issue, making the check redundant, unikraft/lib-compiler-rt#19 proposes to remove this check altogether and I've got a soon-to-be-PRed patch for libunwind that lets it simply select LIBCOMPILER_RT without issue.

[andreittr]

After some more consideration, I believe there are, despite its downsides, still several strong arguments in favour of using Kconfig dependency instead of erroring out:

• it reflects the true dependencies between software in the configuration stage -- after all, that's why we use Kconfig and not just manually toggle compiler defines until something builds
• (related to previous) it prevents generating an invalid config file without warning, IMO something important for maintaining the user's trust in the config system
• other instances of erroring out due to bad config are all AFAIK (temporary) workarounds for limitations in Kconfig:
  • circular dependency between compiler-rt and libunwind (going away as we speak)
  • constraints on numeric option in Python 3 (an upgrade from it silently rewriting your config file -- IMO even worse, can drive users crazy)

I also think the downside of the library being hidden with depends on can be mitigated somewhat:

• the lib can be found by search, and the result page specifies all dependencies (I've actually used this a lot in other Kconfig trees from linux & buildroot)
• some frontends (e.g., nconfig) allow you to display hidden items
• (for the future) we can look into a Kconfig mechanism to provide select-able defaults for subsystems that have multiple implementations (e.g., REQUIRE_LIBC that selects a (pre-configured) default libc); this will remove the issue altogether, but is something for another PR.

Thoughts? @StefanJum @mariasfiraiala @razvand

[StefanJum]

After some more consideration, I believe there are, despite its downsides, still several strong arguments in favour of using Kconfig dependency instead of erroring out:

Agree with the points, it's clearly a lot better to generally have config dependencies instead of build errors.

The only thing I really don't like it's the verbosity of the config dependencies. If we error out at the build it can be clear for everyone what's missing. If we have some weird config dependencies, there is no way to figure them out other than looking in the libraries Config.uk, which is not what a somewhat beginner user will do.

That being said, I'm totally fine with a dependency like this one (depends on HAVE_LIBC). It's simple enough to not worry too much about it.
I'm worried about stuff like A depends on B, B depends on C, C depends on ..., but we can burn that bridge when we get to it. So yeah, we can go ahead with this one.

[StefanJum]

@razvand you can do your magic.
Reviewed-by: Stefan Jumarea stefanjumarea02@gmail.com

[andreittr]

I'm worried about stuff like A depends on B, B depends on C, C depends on ..., but we can burn that bridge when we get to it. So yeah, we can go ahead with this one.

I think you could get into this situation only if B, C and so on are all stuff like libc that have multiple implementations (otherwise we'd just use a select). But let's hope we can get the REQUIRE_* mechanism working for the handful of features with alternate implementations before we start getting deep dependency trees.

[StefanJum]

I think you could get into this situation only if B, C and so on are all stuff like libc that have multiple implementations (otherwise we'd just use a select). But let's hope we can get the REQUIRE_* mechanism working for the handful of features with alternate implementations before we start getting deep dependency trees.

Yes, exactly 🙏

[razvand]

Approved-by: Razvan Deaconescu razvand@unikraft.io