NCS does not build correctly if 'memfault' module sources are not present

[David Palchak]

Our codebase is configured to use West to manage our code repository as well as the NCS repositories. We use the 'name-whitelist' option in our `west.yml` to only import the NCS sub-modules that we use. We currently limit the NCS sub-modules to the following:

- zephyr
- mcuboot
- nrfxlib
- hal_nordic
- trusted-firmware-m
- tfm-mcuboot
- cmock
- unity
- mbedtls-nrf
- nanopb
- cddl-gen

When limiting the NCS submodules to this set, NCS produces build-time errors during the Kconfig step. Specifically, the `nrf/modules/memfault/Kconfig` file has to be manually edited to remove the reference to `MEMFAULT_HTTP_PERIODIC_UPLOAD_USE_DEDICATED_WORKQUEUE`.

It appears that the `nrf/modules/memfault/Kconfig` file implicitly assumes that the `memfault` module sources are always present, which breaks the modularity implied by the word "module". NCS should not depend on any module sources in order to build correctly.

[Torsten Rasmussen]

Hi David,

I agree that the dependency to memfault should not be that strong.

And as you notice, this is one of the tricky parts with Kconfig once you start referring to symbols from external Kconfigs if trying to remove the module.

We are currently discussing two different approaches for handling such cases, you are free to see both proposals here:

https://github.com/nrfconnect/sdk-nrf/pull/6080

https://github.com/nrfconnect/sdk-nrf/pull/6081

You are welcome to pick one of those into your own fork, which will allow you to continue your work.

Best regards

Torsten

[David Palchak]

I commented on the github issue, but I'll leave the same comment here. I personally think that the option expressed in #6081 is cleaner, simpler, and more explicit. It also provides a better example for how downstream user projects might accomplish the same thing with their own optional modules.