Firebase Cpp Builder Agent Skill

Instructions and workflows for building the Firebase C++ SDK natively. Use this skill when you need to compile the C++ SDK per-product (e.g., auth, database) across different platforms (Desktop, iOS, Android).

966 tokens

context cost

the whole folder, loaded on every use

files

instructions only

copies elsewhere

how many repositories repackaged it

323

stars on the repo

on the repository, not the skill itself

Install

one command, takes just this skill from the repository

npx skills add https://github.com/firebase/firebase-cpp-sdk --skill firebase-cpp-builder

The instruction itself

7 sections, as written by the author

Building the Firebase C++ SDK

This skill provides instructions on how to build the Firebase C++ SDK directly

from source, specifically tailored for building individual products (like

firebase_auth, firebase_database, etc.).

Prerequisites

Before building, ensure that your Python environment is set up with all required dependencies, especially if you plan to use helper scripts:

Python Dependencies: Run pip install -r scripts/gha/python_requirements.txt to install required libraries (such as attrs, absl-py, etc.).

1. Desktop Builds (Mac, Linux, Windows)

The easiest way to build for Desktop is to use the Python helper script from the

repository root:

python3 scripts/gha/build_desktop.py -a <arch> --build_dir <dir>

_(Plenty more options: run python3 scripts/gha/build_desktop.py --help for

info.)_

Alternatively, you can build manually with CMake. The build process will

automatically download necessary dependencies.

mkdir desktop_build
cd desktop_build
cmake ..
cmake --build . --target firebase_<product> -j

_Example: cmake --build . --target firebase_auth -j_

2. iOS Builds

For iOS, you can use the convenience script from the repository root:

./build_scripts/ios/build.sh -b ios_build_dir -s .

_(Run ./build_scripts/ios/build.sh -h for more options.)_

Alternatively, you can use CMake's native Xcode generator manually. Ensure you

have CocoaPods installed if building products that depend on iOS SDK Pods.

mkdir ios_build
cd ios_build
cmake .. -G Xcode -DCMAKE_SYSTEM_NAME=iOS
cmake --build . --target firebase_<product> -j

Alternatively, you can build XCFrameworks using the helper script:

python3 scripts/gha/build_ios_tvos.py -s . -b ios_tvos_build

3. Android Builds

For Android, use the convenience script from the repository root:

./build_scripts/android/build.sh android_build_dir .

_(You can also specify an STL variant with the 3rd parameter. Run the script

without any parameters to see the usage.)_

Alternatively, when building the Firebase C++ SDK manually for Android, the

repository uses a Gradle wrapper where each product has its own subproject.

To build a specific product's AARs, run the gradle build task for that module:

./gradlew :<product>:build

_Example: ./gradlew :auth:build or ./gradlew :database:build_

Note that as part of the build process, each library generates a ProGuard file

in its build directory (e.g., <product>/build/<product>.pro).

CMake Target Naming Convention

When using CMake directly (for Desktop or iOS/tvOS), the targets are

consistently named firebase_<product>.

Common targets include:

firebase_app
firebase_analytics
firebase_auth
firebase_database
firebase_firestore
firebase_functions
firebase_messaging
firebase_remote_config
firebase_storage

Product Naming Disambiguation (`firebase_auth` vs `auth`)

Different build tools use different naming conventions for products in this repository:

CMake Targets (Desktop/iOS): Typically prefixed with firebase_ (e.g., firebase_auth).
Gradle Subprojects (Android): Typically use the raw module name (e.g., :auth:build).
Python Scripts (e.g., build_desktop.py, build_testapps.py): Typically use the raw module name (e.g., --t auth).

> [!TIP]

> If you are unsure about the exact product name or supported flags, run Python scripts with --help (e.g., build_desktop.py --help). For shell scripts, run without parameters (Android) or with -h (iOS) to see usage.

Other skills for the same job

different authors, same section of the catalogue

Bioservices

by christophacham

×3

Unified Python interface to 40+ bioinformatics services. Use when querying multiple databases (UniProt, KEGG, ChEMBL, Reactome) in a single workflow with consistent API. Best for cross-database analysis, ID mapping across services. For quick single-database lookups use gget; for sequence/file manipulation use biopython.

Python library for working with geospatial vector data including shapefiles, GeoJSON, and GeoPackage files. Use when working with geographic data for spatial analysis, geometric operations, coordinate transformations, spatial joins, overlay operations, choropleth mapping, or any task involving reading/writing/analyzing vector geographic data. Supports PostGIS databases, interactive maps, and integration with matplotlib/folium/cartopy. Use for tasks like buffer analysis, spatial joins between datasets, dissolving boundaries, clipping data, calculating areas/distances, reprojecting coordinate systems, creating maps, or converting between spatial file formats.

Fast CLI/Python queries to 20+ bioinformatics databases. Use for quick lookups: gene info, BLAST searches, AlphaFold structures, enrichment analysis. Best for interactive exploration, simple queries. For batch processing or advanced BLAST use biopython; for multi-database Python workflows use bioservices.

Direct REST API access to UniProt. Protein searches, FASTA retrieval, ID mapping, Swiss-Prot/TrEMBL. For Python workflows with multiple databases, prefer bioservices (unified interface to 40+ services). Use this for direct HTTP/REST work or UniProt-specific control.

BullMQ expert for Redis-backed job queues, background processing, and reliable async execution in Node.js/TypeScript applications. Use when: bullmq, bull queue, redis queue, background job, job queue.

2k tokens

Moodle External API Development

by ComeOnOliver

×2

Create custom external web service APIs for Moodle LMS. Use when implementing web services for course management, user tracking, quiz operations, or custom plugin functionality. Covers parameter validation, database operations, error handling, service registration, and Moodle coding standards.