Gradle native builds about profilo

[BurntBrunch]

Hi @dbworku,

Thanks for your interest!
Before I go into the steps we would need to get there, let's talk a bit about the proximal issue - duplicate classes.

Would it help if we published an aar that did not bundle any of these other libraries, as well as instructions on the full list of libraries to add to the build? This would be fairly doable (I think) and would not require full maven/gradle builds.

As for gradle, there are a number of considerations:

1. The Java code would be pretty easy to deal with but the native code is where things get tricky. Our source of truth would always be buck build files, so having a tool that introspects the buck build graph and replicates it in cmake would be by far the easiest long-term approach (but with the highest upfront cost). There are, however, features of buck that are hard to replicate in cmake so we might need to refactor the code base significantly and impose new invariants before doing so.
   a. For example, our usage of header_namespace means that the cmake build will have to create a folder structure to symlink the headers into and expose that to dependent libraries. It's not impossible, just tedious to script.
   b. Our usage of header_namespace is questionable in its own right and I wouldn't be opposed to refactors that cleaned it up, so that e.g. cpp/ can be added as a header path across all compiler invocations.
   c. An alternative naive approach would supply recording versions of the toolchain or inspect the buck logs to produce the exact same sequence of invocations via cmake. This would work fairly well but would be somewhat fragile. We could automate it, however, so that every commit landing in github has a correct CMakeLists generated.
2. Barring the automatic cmake conversion, another approach would be to have gradle shell out to buck and pull the built libraries that way. This unfortunately means we wouldn't pick up global flags without extra work and would impose a buck setup cost to people anyway. It's limited in utility but would unblock adding the library to existing projects, assuming that you are okay with the buck setup hurdle.
3. Gradle/cmake will produce suboptimal results, size-wise. For example, this one line completely changes the way buck compiles the native code. It first produces object files, inspects which symbols libraries need from their dependencies and then hides all other symbols when linking the dependencies. This allows us to not worry about manually curating the dynamic symbol table and always produces optimal symbol tables. Replicating this functionality would be very difficult and as a result the gradle build is likely to be significantly bigger than the buck build.

Let me know if you're interested in either the no-deps aar build or the cmake conversion approaches, I'm happy to discuss them in more detail!