CommonCpp/Tools is used by every other native project,
as a proof-of-concept, try to incorporate the code as a separate
library.
https://linear.app/comm/issue/ENG-3003
Depends on D6721
Paths
| Differential D6722 Authored by • jon on Feb 13 2023, 11:38 AM.
Details
Summary CommonCpp/Tools is used by every other native project, https://linear.app/comm/issue/ENG-3003 Depends on D6721 Test Plan Android build gate passes Local dev workflow also works. # start keyserver and native yarn dev processes (cd keyserver && yarn dev &) (cd native && yarn dev &) cd native && yarn react-native run-android
Diff Detail
Event TimelineHerald added subscribers: tomek, ashoat. · View Herald TranscriptFeb 13 2023, 11:38 AM2023-02-13 11:38:43 (UTC-8) Harbormaster returned this revision to the author for changes because remote builds failed.Feb 13 2023, 11:40 AM2023-02-13 11:40:14 (UTC-8) Harbormaster completed remote builds in B16460: Diff 22504.Feb 13 2023, 12:27 PM2023-02-13 12:27:49 (UTC-8) Comment Actions 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... Comment Actions 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.
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.
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.
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.
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:
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.
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. This revision is now accepted and ready to land.Feb 14 2023, 10:35 AM2023-02-14 10:35:13 (UTC-8) Comment Actions Happy to land this now, but let's discuss tomorrow RE ways to reduce JNI boilerplate for devs Comment Actions Going to go back to the drawing boards for this. We should really be separating out the JNI code so that it's part of the existing comm_jni_module (e.g. native/android/app/CMakeLists.txt), and the code held in native/cpp/CommonCpp can just contain non-JNI C++ code. This would allow for us to avoid doing the System.loadLibrary() call, needing to make a shared library, and linking against numerous libraries (e.g. fbjni). Related issue: https://linear.app/comm/issue/ENG-2996 This revision is now accepted and ready to land.Feb 21 2023, 6:50 AM2023-02-21 06:50:13 (UTC-8) Harbormaster completed remote builds in B16699: Diff 22852.Feb 21 2023, 7:05 AM2023-02-21 07:05:50 (UTC-8) Comment Actions going to ask for another review, as this has significantly changes since it was accepted This revision is now accepted and ready to land.Feb 27 2023, 7:26 AM2023-02-27 07:26:49 (UTC-8) Harbormaster completed remote builds in B17321: Diff 23722.Mar 14 2023, 9:50 AM2023-03-14 09:50:03 (UTC-7) Closed by commit rCOMM6f883b5879f0: [Android] Reference Tools by CMake project (authored by • jon). · Explain WhyMar 20 2023, 7:45 AM2023-03-20 07:45:07 (UTC-7) This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 22504 native/android/app/CMakeLists.txt
native/android/app/build.gradle
native/android/app/src/main/java/app/comm/android/MainApplication.java
native/cpp/CommonCpp/Tools/CMakeLists.txt
|