I tried to test the coro.ino example on an STM32 board using the Arduino framework in PlatformIO. I am running into some errors. In ghostl.h there a numerous #ifdefs and #if !defined( statements which are ESP* or SAMD51 specific.
These various macros appear to enable support code which reimplements parts of the the C++ standard library.
It seems like these tests are searching for these particular board specific defines instead of using more general macros which might be enabled in a board specific manner.
I would love to suggest to use the C++ feature test macros which should be available on any compiler that supports C++ 20 coroutines, but I am not sure if there is a general way to test for the availability of and current #include status of the standard library headers that you require.
I am hesitant to supply patches to search for STM32 compiler definitions if they don't address this deeper issue or at least split out the board specific tests from the various workaround #ifdefs. I feel like every supportable board will soon be littering the codebase in #ifdefs strewn throughout the various header files.
E.g. ghost.h:L34-40
#if !defined(ARDUINO_ARCH_SAMD) && !defined(ESP8266)
typedef enum memory_order {
memory_order_relaxed,
memory_order_acquire,
memory_order_release,
memory_order_seq_cst
} memory_order;
the following should be equivalent and board agnostic.
#ifdef GHOSTL_INTERNAL_ATOMIC_MEMORY_ORDER
typedef enum memory_order {
memory_order_relaxed,
memory_order_acquire,
memory_order_release,
memory_order_seq_cst
} memory_order;
then in a board_defs.h or something similar
#ifdef ESP8266
#define GHOSTL_HAS_STD_LIBRARY
...
#endif /* ESP8266 */
#ifdef ARDUINO_ARCH_SAMD
#define GHOSTL_HAS_STD_ATOMIC
...
#endif /* ARDUINO_ARCH_SAMD */
#ifdef STM32_CORE_VERSION
#define GHOSTL_HAS_STD_LIBRARY
...
#endif /* STM32_CORE_VERSION */
#ifdef ARDUINO
# if !defined(GHOSTL_HAS_STD_LIBRARY) && !defined(GHOSTL_HAS_STD_ATOMIC)
# define GHOSTL_INTERNAL_ATOMIC_MEMORY_ORDER
# endif /* !defined(GHOSTL_HAS_STD_LIBRARY) && !defined(GHOSTL_HAS_STD_ATOMIC) */
#ifndef GHOSTL_HAS_STD_LIBRARY
# define GHOSTL_INTERNAL_ARRAY
# define GHOSTL_INTERNAL_UNIQUE_PTR
# define GHOSTL_INTERNAL_FUNCTION
# define GHOSTL_INTERNAL_IDENTITY
# define GHOSTL_INTERNAL_FORWARD
#endif /* GHOSTL_HAS_STD_LIBRARY */
#endif /* ARDUINO */
In this way users can add -DGHOSTL_HAS_STD_LIBRARY to their compile definitions and not have to even edit the board_defs.h. Popular boards / platforms can be added to board_defs.h if testing shows that they are compatible with ghostl.
I tried to test the coro.ino example on an STM32 board using the Arduino framework in PlatformIO. I am running into some errors. In ghostl.h there a numerous
#ifdefsand#if !defined(statements which are ESP* or SAMD51 specific.These various macros appear to enable support code which reimplements parts of the the C++ standard library.
It seems like these tests are searching for these particular board specific defines instead of using more general macros which might be enabled in a board specific manner.
I would love to suggest to use the C++ feature test macros which should be available on any compiler that supports C++ 20 coroutines, but I am not sure if there is a general way to test for the availability of and current #include status of the standard library headers that you require.
I am hesitant to supply patches to search for STM32 compiler definitions if they don't address this deeper issue or at least split out the board specific tests from the various workaround #ifdefs. I feel like every supportable board will soon be littering the codebase in #ifdefs strewn throughout the various header files.
E.g. ghost.h:L34-40
the following should be equivalent and board agnostic.
then in a board_defs.h or something similar
In this way users can add -DGHOSTL_HAS_STD_LIBRARY to their compile definitions and not have to even edit the board_defs.h. Popular boards / platforms can be added to board_defs.h if testing shows that they are compatible with ghostl.