* For iOS 15.5, refactor how MGL Expressions are defined. Fix for "NSExpression function is forbidden" #331 * Convert CI Scheme to TestPlan. Add CI-Expressions TestPlan (which skips tests unrelated to `NSExpression`) * Update Swift & Objective-C sample Code for MGL Expressions. Use these patterns for fixing unit tests. * Update Swift sample code & documentation for MGL expressions. Update API docs (.h) & online docs (HTML) with: `make darwin-style-code && make idocument` * Refresh developer documentation for: build dependencies, running unit tests from the command line, and logging in C++. * Mark certain unit tests as "Expected Failures": Awaiting unit test refactoring for https://github.com/maplibre/maplibre-gl-native/issues/331 * Update to latest Xcode & iOS SDK. Update GitHub Action Runner Images from https://github.com/actions/runner-images * For iOS 15.5, add "Expected Failure" for tests * Skip failing test unrelated to NSExpressions * Convert macOS project to use Test Plans * Exclude previously failing Offline Storage test * Refactor MGL Match expressions for macOS & iOS 15.5 * Refactor Unit Tests so that "Excluded Failures" work for both macOS 12 & iOS 15.5 * Refresh documentation on how to test for macOS from the command line
5.5 KiB
Developing
This is been rewritten to include:
- How to build for the platforms we support.
- Acceptance criteria for code contributions (style, static asserts)
- How to run the unit tests.
- How to run the benchmarks.
- How to rebaseline baselines metrics.
- How to use GL Native as a 3rd party library in your project.
Render Tests
To check that the output of the rendering is correct, we compare actual rendered PNGs for simple styles with expected PNGs. The content of the tests is stored in the MapLibre GL JS submodule which means that GL JS and Native are in fact quasi pixel-identical in their rendering.
The directory sturcture of the render tests looks like:
maplibre-gl-js/
test/
integration/
render-tests/
<name-of-style-spec-feature>/
<name-of-feature-value>/
expected.png
style.json
After the render test run, the folder will also contain an actual.png file and a diff.png which is the difference between the expected and the actual image. There is a pixel difference threshold value which is used to decide if a render test passed or failed.
Building the render test runner
Run the following on linux to build the render test runner:
git submodule update --init --recursive --depth 1
sudo apt update
sudo apt install ccache cmake ninja-build pkg-config xvfb libcurl4-openssl-dev libglfw3-dev libuv1-dev g++-10 libc++-9-dev libc++abi-9-dev libpng-dev libgl1-mesa-dev libgl1-mesa-dri libjpeg-turbo8 libicu66 libjpeg-dev
cmake . -B build -G Ninja -DCMAKE_CXX_COMPILER_LAUNCHER=ccache -DCMAKE_C_COMPILER=gcc-10 -DCMAKE_CXX_COMPILER=g++-10
cmake --build build -j $(nproc 2>/dev/null || sysctl -n hw.ncpu 2>/dev/null)
Running the render tests
On linux, run all render tests with:
./build/mbgl-render-test-runner --manifestPath metrics/linux-clang8-release-style.json
Or a single test with:
./build/mbgl-render-test-runner --manifestPath metrics/linux-clang8-release-style.json --filter "render-tests/fill-visibility/visible"
On macOS, run all render tests with:
./build/mbgl-render-test-runner --manifestPath metrics/macos-xcode11-release-style.json
Inspecting render test results
The render test results are summarized in a HTML website located next to the manifest file. For example, running metrics/linux-clang8-release-style.json produces a summary at metrics/linux-clang8-release-style.html.
MapLibre & C++
MapLibre makes use of a common set of C++ files for iOS, macOS, Android, Linux & QT. See platform/default/src/mbgl/,
or any of the platform make files:
platform/android/android.cmakeplatform/ios/ios.cmakeplatform/linux/linux.cmakeplatform/macos/macos.cmakeplatform/qt/qt.cmake
Debugging
- Android developers can use Android Studio or
ndk-gdb - iOS developers can use Xcode. See also Advanced Debugging with Xcode and LLDB.
Logging in C++
- Android developers can review NDK logging at developer.android.com/ndk/reference/group/logging.
- iOS developers can review Logging at developer.apple.com/documentation/os/logging.
Example Cross Compile Logging for Android & iOS
Add this to your header.
#include <iostream>
#include <sstream>
#define LOG_TAG "# MapLibre "
#ifdef __ANDROID__
#include <android/log.h>
#endif
Then you can use this sample code which compiles for both Android & Xcode.
std::stringstream message;
// Set your message to log.
message << LOG_TAG << __FUNCTION__ << " req->resource.url = " << req->resource.url << std::endl;
// Logs to Xcode console.
std::cout << message.str();
#ifdef __ANDROID__
// Logs to Android Logcat.
__android_log_print(ANDROID_LOG_DEBUG, LOG_TAG, "%s", message.str().c_str());
#endif
Which will log the following samples.
Android Sample Logging Output
com.mapbox.mapboxsdk.testapp D/# MapLibre: online_file_source.cpp: # MapLibre: online_file_source.cpp activateRequest req->resource.url = https://api.maptiler.com/tiles/v3/tiles.json
Xcode Sample Logging Output
MapLibre: online_file_source.cpp activateRequest req->resource.url = https://demotiles.maplibre.org/style.json
Autocomplete with make
MapLibre makes use of several command line tools for local and cloud builds.
To see what targets exist you have to review the Makefile, which can be tedious.
There is a better way with the Zsh. While in a folder with a Makefile, you can type make followed by hitting <tab> twice.
cd platform/android
make android # <tab><tab>
# Example, Android make targets starting with `ap`
# apackage aproj
# ----
cd platform/ios
make ios # <tab><tab>
# Example, iOS make targets starting with `ios`
# ios ios-lint ios-sanitize ios-test
make macos # <tab><tab>
# Example, macOS make targets starting with `macos`
# macos macos-lint macos-test
To add this feature add the following to your zsh.
# open ~/.zprofile
# Autocomplete for `make` when in a directory
zstyle ':completion:*:*:make:*' tag-order 'targets'
autoload -Uz compinit && compinit