Summary:
This PR adds support for using SonarKit clients in Swift apps. Fixes#13, fixes#87
1. Swift can't import Obj-C modules which have C++ headers. For this reason, we use SonarKit as an Obj-C++ wrapper around Sonar, which is written in C++. Due to search path misconfiguration, trying to import SonarKit into a Swift project would import `xplat/Sonar/SonarPlugin.h` instead of `iOS/SonarKit/SonarPlugin.h`, which caused `file not found` errors for C++ stdlib imports like #28 because new projects don't have their search paths set up correctly.
2. The network and layout plugins have C++ definitions (struct methods, classes) in some of their headers. This causes the compiler to get confused for Swift projects, because it only supports importing Objective-C files in umbrella headers, meaning that the `SonarKit` won't build.
1. I updated the `HEADER_SEARCH_PATHS` of SonarKit.podspec's build configuration to include `${PODS_ROOT}/Headers/Private/SonarKit/**` first, which alleviates the search path issue. The Obj-C `Sample` project seems to have worked around this by including a hardcoded `${PODS_ROOT}/SonarKit/**` search path in the pbxproj, which is why Sample works but new projects (like those referenced in #28) don't. I removed this since it's no longer necessary.
2. I added a `SampleSwift` app to demonstrate using Sonar with a Swift project.
3. Because the Podfiles for `Sample` and `SampleSwift` referenced podspecs using `:podspec` instead of a concrete version, Cocoapods wouldn't copy local header files (instead, it downloads them from the source). To enable local development of these sample apps using `:path`, I added a symlink to SonarKit.podspec in the root of the directory.
4. I changed SonarKit.podspec to use a tag-based `source`, since v0.0.1 pulls from the master branch of this repo.
The layout and network plugins still don't work with Swift - in order to fix this, we'll need to work on extracting the C++ out of their headers and writing Obj-C++ wrappers for them. I decided to push this off to a later PR since this one is quite large already.
This means that we need to be able to `import SonarKit` without importing all the network/layout plugin headers. In order to make this work, I made "SonarKit/Core" the spec's `default_subspecs`.
priteshrnandgaonkar, let me know if you have any thoughts on this implementation. You can verify that the SampleSwift app works by checking out this branch, `pod install`ing in the SampleSwift directory, and building it :)
Pull Request resolved: https://github.com/facebook/Sonar/pull/106
Reviewed By: jknoxville
Differential Revision: D8890010
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 449305bcc5cbeb5787c23f51b1ecb80a5cbdad32
Summary: SonarConnection should have an `error` function; this stubs out the mock to have this, allowing creation for tests.
Reviewed By: jknoxville
Differential Revision: D8878130
fbshipit-source-id: 9e0f45dac4ba31ee650dfd46dcee51207cc7a9b4
Summary:
This diff adds the support to automate iOS releases. This diff adds two scripts, one for updating all the `podspecs`, and `podfiles` with updated version number. The script also updates the version used in sample and getting started doc file.
The second script publishes a github tag.
Following will be the process for iOS release:-
1. From `fbobjc/Libraries/SonarKit/Scripts` run `sh public-ios-podspec-update.sh`, it will update all the podspecs, podfiles and docs with updated version number. Commit it and land this
2. Once the above changes are landed and synced to github, run `sh push-new-github-tag.sh` from `fbobjc/Libraries/SonarKit/Scripts` to push the tag on github
As a follow up on this diff, ideally, we should trigger second script automatically when the 1st task changes are synced to github.
Reviewed By: jknoxville
Differential Revision: D8879958
fbshipit-source-id: 8f0dc9200e8f64578af33e1446629f09c16c43f2
Summary:
This moves the native setup to a separate gradle file and unpacks everything outside the build folder. That way we don't throw everything away on every incremental build.
This is an intermediate step to get to a more declarative setup like Fresco has it and get rid of the individual hacks we have for every download.
Pull Request resolved: https://github.com/facebook/Sonar/pull/154
Reviewed By: jknoxville
Differential Revision: D8833812
Pulled By: passy
fbshipit-source-id: 2424c9d6e22e6092c04af344e06939b4a6aba041
Summary:
This diff uses `tag` instead of master branch and also updates the version number to the desktop sdk.
Pull Request resolved: https://github.com/facebook/Sonar/pull/152
Reviewed By: danielbuechele
Differential Revision: D8820016
Pulled By: priteshrnandgaonkar
fbshipit-source-id: ff2e554be55254b77c4e130b35b7299abbafa77d
Summary:
Compile against a static version of OpenSSL for better compatibility
with apps that already use OpenSSL in some fashion.
Pull Request resolved: https://github.com/facebook/Sonar/pull/149
Reviewed By: priteshrnandgaonkar
Differential Revision: D8804169
Pulled By: passy
fbshipit-source-id: 4de66a77806a3b3f01b2cf5f253916f2cf6f48e8
Summary:
One design goal of sonar is to never cause the host app to crash or hang.
For this reason, we do all heavy work in a background thread.
If we detect that it's not running in it's own thread, just return so we don't hold up the caller.
Reviewed By: danielbuechele
Differential Revision: D8767288
fbshipit-source-id: e146cc2cfe5c3e62d12f527ff79f24c74873d4ff
Summary:
Having another attempt at removing this. It's unsafe because it in some cases executes the .then() task in the timekeeper thread, rather than the executor the original future is using.
When that default executor is an InlineExecutor, for example, you can get stack overflow.
I tried to remove this use before, but having the same thread used for both the sonar client itself and rsocket, meant that they entered a deadlock trying to connect.
Now that I've separated those jobs into separate threads, they can execute independently.
Reviewed By: danielbuechele
Differential Revision: D8748356
fbshipit-source-id: a1029ece2c7006ad7642cbf8aa59e692c76b19b2
Summary:
We currently give sonar one event base from java / obj-c code to use for scheduling tasks.
This causes a problem, because we schedule reconnect tasks on the event base, and then these tasks interact with rsocket which schedules it's own tasks.
The problem is that we're passing rsocket the same event base. So the reconnect code executes and blocks waiting for rsocket to connect.
But rsocket can never connect because it never executes because that thread is blocked, so we get deadlock.
This is the first step which just changes the interface to pass two event bases.
The consumers will be changed to pass in different threads next.
Reviewed By: danielbuechele
Differential Revision: D8748350
fbshipit-source-id: 481d6f23644f28fd0f1c786252605287019c999c
Summary:
This uses OpenSSL 1.1.0h to build and link against. The `.so`s are
precompiled and hand-patched from [this
repository](https://github.com/passy/android-database-sqlcipher). The
patching was necessary to fix the `SONAME` and corresponding `NEEDED`
flags to *not* contain a `.1.1` version suffix as Gradle will refuse to
bundle those.
We basically only use the headers for the remaining part.
The precompiled version contains ABI support for `arm64-v8a`, `armeabi`,
`armeabi-v7a`, `x86` and most importantly `x86_64`. HOWEVER, `x86_64` is
still excluded for now because folly fails to compile due to a missing
compiler flag:
```
error: needs target feature pclmul
```
This should be easily fixable by ensuring that `-mpclmul` is added to
the CFLAGS if we're compiling for an `x86_64` target in the
`CMakeLists.txt` for Folly.
Closes#113.
Closes https://github.com/facebook/Sonar/pull/125
Reviewed By: priteshrnandgaonkar
Differential Revision: D8723636
Pulled By: passy
fbshipit-source-id: 41c61047d2793ebaef5793a3c937c4d628471d6a
Summary:
Set up our fbjni sub-project to be published to Maven Central.
This removes a bunch of abiFilters that we no longer make use of, too.
Closes https://github.com/facebook/Sonar/pull/119
Reviewed By: priteshrnandgaonkar
Differential Revision: D8694537
Pulled By: passy
fbshipit-source-id: de246fbda99c02856fbc7806b78df2114cb82acb
Summary:
delayedUnsafe() is unsafe because it disregards the executor you have specified, and uses the default one.
Depending on the context, this can sometimes be an InlineExecutor, and since some of the scheduled jobs, schedule instances of themselves, this can cause infinite recursion to occur.
Fixing this by using the safe variant of delayed, and also using a new instance of IOExecutor.
We need a new Executor for the Sonar loop, because if we use the same worker thread as is provided to RSocket, we get deadlock when we wait for rsocket to connect.
Reviewed By: danielbuechele
Differential Revision: D8617679
fbshipit-source-id: 51ab3224b93e774596a8799338e7391e2eb956cb
Summary:
There's an issue with folly's delayedUnsafe(), where it drops your executor and effectively
runs all futures inline, in this case instead of scheduling tasks for the future, it grows the stack indefinitely.
This fixes the issue by using the safe delayed(), which preserves the executor, so the jobs get shceduled on a different thread as intended.
Reviewed By: LeeHowes
Differential Revision: D8575956
fbshipit-source-id: c5b2ced43a70505c51883281f202ac947ae6723f
Summary:
When an app with sonar is run for the first time, the necessary files don't exist.
This is expected, so don't output an error, only error if they do exist but there's some other problem.
Reviewed By: emilsjolander
Differential Revision: D8350995
fbshipit-source-id: ff0a4f0e7a73848f6172c6108a0caee6efb43553
Summary:
If the app has an old CSR with data that is incompatible with sonar, we can't use it.
An example of this happening is when we moved the package name from organisation to common name in the certificate subject.
To get around this, always create a new one to guarantee it contains what we expect.
Reviewed By: emilsjolander
Differential Revision: D8350247
fbshipit-source-id: e53148fcddc47aa60e3daef5bbf36ce330a3b4e9
