lib: cpp: Introduce FULL_LIBCPP_SUPPORTED similar to C version

[galak]

Introduce Kconfig symbol FULL_LIBCPP_SUPPORTED that is similar to the C version FULL_LIBC_SUPPORTED. This way we can utilize the same pattern in tests and samples to filter for when a full libc++ is needed.

[galak]

plan to use this for thrift samples to start.

[cfriedt]

plan to use this for thrift samples to start.

In true FB fashion, there is yet another thrift that has been open-sourced.

https://github.com/facebook/fbthrift

This one seems like it would be significantly less resource intensive because it uses std::coroutine and std::string_view.

I would love to put together an ISO C code generator on the other hand.. Apache Thrift relies on glib unfortunately

[keith-packard]

Would be good to see this in actual use to make sure it works as advertised.

[stephanosio]

Since we are adding FULL_LIBCPP_SUPPORTED, shall we add MINIMAL_LIBCPP_SUPPORTED, GLIBCXX_LIBCPP_SUPPORTED and others as well?

[galak]

Since we are adding FULL_LIBCPP_SUPPORTED, shall we add MINIMAL_LIBCPP_SUPPORTED, GLIBCXX_LIBCPP_SUPPORTED and others as well?

I figured we would add them if they where needed.

[galak]

Would be good to see this in actual use to make sure it works as advertised.

Here's how this would be used:

#57097

[galak]

@stephanosio do you think we should add select FULL_LIBCPP_SUPPORTED for EXTERNAL_LIBCPP? Should we also limit EXTERNAL_LIBCPP to NATIVE_APPLICATION. Since it seems to exist purely for native_posix from what I can tell.

[stephanosio]

do you think we should add select FULL_LIBCPP_SUPPORTED for EXTERNAL_LIBCPP?

No, because EXTERNAL_LIBCPP in itself does not imply a full standard C++ library (e.g. one could provide their own standard C++ library, similar to the Zephyr minimal C++ library, that implements a limited subset of the standard C++ library).

Should we also limit EXTERNAL_LIBCPP to NATIVE_APPLICATION. Since it seems to exist purely for native_posix from what I can tell.

No, because this option is intended to be selected when an external standard C++ library is used (e.g. when user/application supplies their own standard C++ library).

So, I would say we should leave the selection of the FULL_LIBCPP_SUPPORTED up to whoever/whatever is supplying that LIBCPP.

In case of the NATIVE_APPLICATION, it should select FULL_LIBCPP_SUPPORTED based on the aforementioned reasoning; in fact, it already selects FULL_LIBC_SUPPORTED:

zephyr/Kconfig.zephyr

Lines 317 to 319 in 58088f3

	config NATIVE_APPLICATION
	bool "Build as a native host application"
	select FULL_LIBC_SUPPORTED