Abtor: A Custom C++ Build Tool and Amap CI for Scalable Development at Gaode Map

Gaode Map’s navigation client relies heavily on high‑performance C++ modules for map rendering and routing. With more than 40 modules in the engine library, the existing build and CI infrastructure could no longer keep up with the rapid growth and diverse requirements of multiple business lines (mobile, car‑machine, open platform, etc.).

The main challenges were:

Multi‑team collaboration: Different OSes and IDEs required separate configurations.

Multi‑business‑line customization: Each line (phone, car‑machine, open platform) needed its own build variants.

Car‑machine environments: Highly customized toolchains across many OEMs made per‑device configuration untenable.

Monolithic Git repository: Source code and binary dependencies were mixed, causing large repository size, slow check‑outs, and tangled dependency graphs.

After evaluating traditional C++ build systems (Make, CMake, Bazel, Ninja, SCons) and finding none that satisfied all constraints, Gaode developed a bespoke solution: the Abtor C++ build tool and the Amap CI continuous‑integration platform.

Abtor Overview

Abtor is a cross‑platform C++ build tool written in Python. It generates CMake configuration files, invokes the built‑in CMake component to produce Makefiles, and finally builds the target binaries or libraries. The tool abstracts compiler and linker details, offering built‑in functions for dependency detection, OSS download, and permission‑controlled publishing.

The build workflow is:

Write an Abtor build script.

Parse the script.

Detect dependencies, resolve conflicts, and download required artifacts from Alibaba OSS.

Generate CMakeLists.txt and produce a Makefile via the embedded CMake.

Compile, link, and produce platform‑specific binaries.

Publish the binaries back to OSS.

Additional features include access‑controlled library publishing and fine‑grained permission management.

Key Benefits of Abtor

Broad cross‑platform support: macOS, iOS, Android, Linux, Windows, QNX, etc.

Consistent multi‑team collaboration: One configuration can generate IDE‑specific projects (Xcode, Android Studio, VS2015, Qt Creator, CLion).

High customizability: Flexible tool‑chain and build‑parameter configuration, especially for complex car‑machine builds.

Separation of source and binary dependencies: Source code lives in Git, while compiled libraries are stored in Alibaba Cloud, ensuring clear separation.

Fast build performance for large projects.

Typical project layout (shown in the original article) looks like:

abtor_demo
├── ABTOR
│   └── wrapper
│       ├── abtor-wrapper.properties # configuration file, can specify Abtor version
│       └── abtor-wrapper.py         # downloads Abtor version and invokes entry point
├── abtor.proj                       # core Abtor configuration file
├── abtorw                           # Linux/Mac entry script
├── abtorw.bat                       # Windows entry script
└── src
    └── main.c                       # source file to compile

The core abtor.proj file is also Python‑based, for example:

#!/usr/bin/python
# -*- coding: UTF-8 -*-

# Specify source directories
header_dirs_list = [abtor_path("include")]    # header directories
binary_src_list = [abtor_path("src/main.c")]  # source files

cflags = " -std=c99 -W -Wall "
cxxflags = " -W -Wall "

# Define a binary target
abtor_ccxx_binary(
  name = 'demo',
  c_flags = cflags,
  cxx_flags = cxxflags,
  deps = ["add:1.0.0.0"],               # library dependencies
  include_dirs = header_dirs_list;
  srcs = binary_src_list
)

Dependency Management

Abtor introduces a server‑side service that records library versions in a cloud database. Before a build, Abtor resolves all transitive dependencies, detects version conflicts (e.g., diamond dependencies), and aborts the build if conflicts exist, prompting developers to resolve them.

Amap CI Platform

Amap CI replaces the manual Jenkins jobs with an automated GitLab‑Webhook‑driven pipeline. When a tag is pushed, the webhook triggers the CI backend, which distributes build tasks to registered build machines, handles resource allocation, and orchestrates the entire build‑test‑deploy flow.

Key capabilities of Amap CI include:

Scalable build‑machine registration and auto‑scaling.

Transparent integration with Abtor Server for dependency checks and library downloads.

One‑click tag‑based builds across all platforms.

Automated notifications (DingTalk, email) for build status.

Extensible interfaces for integration with other Alibaba platforms (Titan, CT, Aone).

The platform also implements “whole‑tree linked compilation”. When a library is updated, all dependent libraries are automatically rebuilt in a top‑down order, ensuring consistency across the entire dependency graph.

A sample CI configuration file ( CI_CONFIG.json) looks like:

{
    "mail":"[email protected]",
    "arch":"Android,iOS,Mac,Ubuntu64,Windows",
    "build_vars":"-v -V",
    "modules":{
        "amap":{
            "features":[
                {"name":"feature1","macro":"-DFEATURE_DEMO1=True"},
                {"name":"feature2","macro":"-DFEATURE_DEMO2=True"}
            ]
        },
        "auto":{
            "features":[
                {"name":"feature1","macro":"-DFEATURE_DEMO1=True"},
                {"name":"feature3","macro":"-DFEATURE_DEMO3=True"}
            ]
        }
    }
}

This JSON defines email notifications, target architectures, global build flags, and per‑module feature toggles, enabling fine‑grained multi‑business‑line customization.

Future Outlook

Having evolved over three years, the team plans to extend the toolchain toward a full development‑to‑deployment closed loop, further automating coding, building, testing, delivery, and deployment, thereby freeing engineers to focus on higher‑value work.