at_c: C Release Automation should move root CMakeLists.txt

[JeremyTubongbanua]

After investigation, this does not work unless you have the C SDK installed beforehand. In other words, it won't work for first time users.

FetchContent_Declare(
  atclient
  URL https://github.com/atsign-foundation/at_c/releases/download/v0.1.0/at_c-v0.1.0.tar.gz
  URL_HASH SHA256=494a4960dedc45484a0078db4c388cd592efdebde45e40bdded5c2b9c587b146
  SOURCE_SUBDIR packages/atclient
)

I think it would be worth cp ./CMakeLists.txt and cp -r cmake/ into the build automation

[cpswan]

@JeremyTubongbanua simply copying the root CMakeLists.txt into the tarball doesn't work, because we're archiving the contents of packages but that file expects to find stuff in a subdirectory called packages, which isn't there.

I think we have a couple of options here:

1. Don't have CMakeLists.txt (and the corresponding cmake directory) in the root, but instead relocate it to packages (there could then perhaps be a trivial CMakeLists.txt that just pulls in the one in packages.
2. Maintain duplicate CMakeLists.txt in both the root and packages (and perhaps have a script to generate one from the other so that they stay in sync).

I think my preference is 1, but what are your thoughts?

[JeremyTubongbanua]

Ah, I see

I would be for the idea of permanently moving our ./CMakeLists.txt into something like packages/atsdk/CMakeLists.txt which is just a package that helps you build the entire atsdk (atsdk is composed of atlogger, atclient, and atchops).

Then, I would imagine developers could use FetchContent like so:

FetchContent_Declare(
  atsdk
  URL <...>.tar.gz
  URL_HASH SHA256=<hash>
  SOURCE_DIR packages/atsdk
)

FetchContent_MakeAvailable(atsdk)

We would delete our ./CMakeLists.txt and create a new packages/atsdk/CMakeLists.txt (some engineering would be required to refactor the paths to some of the packages).

Is this what you had in mind @cpswan Let me know your thoughts

[JeremyTubongbanua]

Thoughts in architecture call:

Have a

packages/atsdk/ - which contains a standalone CMakeLists.txt which will build an atsdk target which statically links atclient, atlogger, atchops
packages/atsdk_esp32 - which contains a standalone CMakeLists.txt which will build atsdk target specially built for ESP32

We could even branch out to do things like:

• packages/atsdk_static/
• packages/atsdk_shared/
• packages/atsdk_macos

The pro to doing things this way is that we can engineer many different kinds of CMakeLists.txt for different customer requirements.

If we do it this way, we have to make packages/atclient, packages/atchops, and packages/atlogger very atomic.

We can change the names of these directories. Instead of packages/ it could be named targets/ or builds/ or libraries/

[cpswan]

Moving into PR95 and adding some additional SP

[cpswan]

@JeremyTubongbanua are you going to take care of the refactor you propose above?

[JeremyTubongbanua]

I sure can @cpswan 👍🏼

Feel free to un-assign yourself in the meantime while I pick up this work. Once this work is complete, I think I will create a new ticket for you if I need any help