This is a lot of boilerplate for each "library". Why do we need this? What does it achieve exactly? What's wrong with just compiling all of our code as a monolith, versus separating each folder into its own library?

My instinct is that we should keep the monolith until we have a reason for breaking it up, as it's clear from the amount of boilerplate here that it will be a lot to maintain. Just creating a new folder becomes a scary affair, with a bunch of ossified knowledge about magic incantations that needs to be hidden in some Notion file somewhere...

A lot of these questions would better suited for the person who created the original structure of cpp/CommonCpp. The CMake structure largely just inherits the structure of the directories as there's a similar separation of concern.

This is a lot of boilerplate for each "library".

Yep, but it's also structure; and current best practice for CMake. Also being explicit about what is expected by the project, as well as what the project will produce.

Why do we need this?

Because our CMake hygiene is terrible, and it enables a lot of scenarios which might be beneficial (e.g. unit tests). The question is similar to "why do we need to organize code into separate files and methods". For structure and to manage complexity.

What does it achieve exactly?

It's the first step of allowing Tools to know how to build itself. So we can reference it at a higher level than I'm going to glob all over your files.

What's wrong with just compiling all of our code as a monolith

Technically, nothing. But if that was the case, we should have just a single directory native/cpp/ which contains all of our C++ code. Which I'm not actually opposed to, it would be better than our current over-structured CommonCpp

But not compiling as a single monolith does some benefits:

• Compile times (took me 200-400s to build to this diff with gradle primed, ~30-60s to build the diff with comm-modules-native being referenced
• Unit tests per project (which I understand is not a priority, but also wasn't an option previously)
• Build failures are easier to remedy as the scope is smaller

My instinct is that we should keep the monolith until we have a reason for breaking it up, as it's clear from the amount of boilerplate here that it will be a lot to maintain. Just creating a new folder becomes a scary affair, with a bunch of ossified knowledge about magic incantations that needs to be hidden in some Notion file somewhere...

Trying to augment the current build is also a scary affair. CMake is pretty boilerplate heavy and personally I'm not a fan, but it's what everyone uses for C/C++ now.

with a bunch of ossified knowledge about magic incantations that needs to be hidden in some Notion file somewhere...

I tried to make the CMake as readible as possible, just kind of set up for failure since CMake is has a lot of legacy issues which will continue to make it a very opaque tool. If you're concerned about the structure of the CMake, it just reflects the complexity of the our current C++ codebase.

Happy to land this now, but let's discuss tomorrow RE ways to reduce JNI boilerplate for devs