Direction for making AtomVM easier to embed as a CMake subproject

[yashi]

Hi,

I am trying to embed AtomVM into another C application on Linux.

I can build AtomVM standalone, and the atomvm CLI works with .avm files. My next goal is to use AtomVM as a library from my own CMake project.

While trying this, I noticed that the current CMake target structure seems optimized for building each platform runtime as a top-level build, rather than for embedding AtomVM as a subproject.

My current understanding is that the library dependency graph is effectively circular:

libAtomVM
  -> libAtomVM${PLATFORM_LIB_SUFFIX}

libAtomVM${PLATFORM_LIB_SUFFIX}
  -> libAtomVM

Also, some compile definitions and include directories appear to be propagated to the platform library through the reverse dependency on libAtomVM.

For embedding, I think a cleaner direction may be:

host app / AtomVM executable
  -> libAtomVM
       -> libAtomVM${PLATFORM_LIB_SUFFIX}
       -> atomvm_config

libAtomVM${PLATFORM_LIB_SUFFIX}
  -> atomvm_config

In this model:

libAtomVM is the public runtime target that applications link against.

Platform libraries provide the platform-specific implementation used by libAtomVM.

Platform libraries do not link back to libAtomVM.

Shared compile definitions, include directories, compile features such as C11, and generated configuration headers are carried by an INTERFACE target, for example atomvm_config.

An embedding application would eventually only need to link to libAtomVM.

Does this direction make sense for AtomVM?

A possible incremental plan would be:

1. Add an atomvm_config INTERFACE target for shared compile features, compile definitions, and include directories.
2. Make both libAtomVM and platform libraries consume atomvm_config.
3. Remove platform library -> libAtomVM reverse links.
4. Keep libAtomVM -> platform library as the implementation dependency.
5. Make platform executables link only to libAtomVM where practical.
6. Add a small embedding or subproject build test, possibly starting with generic_unix.

Before going further, I would like to confirm whether this matches the intended AtomVM architecture, or whether there is a reason the platform libraries currently link back to libAtomVM.