build_native 0.0.10

  • Installing
  • Versions
  • 54


Pub License

Compile native extensions with package:build, using the system compilers.

Windows building is not supported YET.


This is a 2-step build process:

  1. Build *.{c,cc,cpp} files to .o.
  2. Link files into a shared library.

Ultimately, to build everything and run a Dart script, you will just need to run pub run build_runner run <script name>.

The goal of this package is to use existing infrastructure to build native extensions.

As an added note, this has not been tested on Linux, but it is developed on Mac, and the two platforms compile extensions almost exactly the same way.


build_native requires only very little configuration. However, this means that it can only serve one purpose: invoking the compiler on the user's system.

Command Line Usage

package:build_native ships with a few commands that can make the native extension experience a bit easier to bear:

Verifying the Environment

To ensure that the system has a compatible compiler available, and that the necessary executables are in the PATH to build extensions, run:

pub run build_native doctor

Generating Extension Boilerplate

Creating native extensions for any language can tend to involve a lot of boilerplate.

To quickly scaffold a new native extension, run:

pub run build_native scaffold

Source Files

Also, because of the nature of package:build, each input can only create one output. For *.c, *.cc, and *.cpp, files, the system compiler is invoked to create a .o file. To override this, set the CC environment variable when compiling C, or the CXX environment variable when compiling C++.

Files named *.macos.{c,cc,cpp} will only build on Mac. The same applies to linux and windows. This can be used to apply platform-specific settings in your build.

Master Build File

To perform linking, include an lib<extension_name>.build_native.yaml file in the directory where the extension should be built.

It should contain a list of source files to link together.

Note that these should all be asset ID's.

The simplest example, libsample_extension.build_native.yaml:

  - example|src/

See example/ for more.

The most common of the supported options:

  - "-O2"
  - example|
  - example| # Will only be included on MacOS; ignored elsewhere
  - some_dir
  - some_other_package|lib/some_file.h # If passing an asset id, you must use a filename.
  - curl
  - readline
  - some_other_package|lib/libsome_extension.build_native.yaml
  foo: bar

Platform-Specific Options

To specify options that should only apply to a given platform, add a <extension_name>.<platform_name>.macos.build_native.yaml file, for example, foo_bar.macos.build_native.yaml. This will be merged into the main options.

Platforms available: macos, windows, linux.

By providing this as the PLATFORM environment variable, you can override this.

Disallowing a Platform

If you know your library will certainly never build on a given system, you can explicitly disallow it, instead of forcing users to first download dependencies before a build failure:

  - linux
  - macos
  - windows

Third-Party Dependencies

Unless you are a maniac and actually intend to write by hand every line of C/C++ code by hand, you might eventually need to pull in some source code from the Internet, so that it can be built alongside your program. Specify the names of dependencies in the third_party section of your configuration:

  git: git://some/repo/here
    - lib # Directories to link against; relative paths.
    - include  # Directories to include from; relative paths.
  sources: # Source files to compile
    - src/main.c
    - src/b/c/d.c

Specifying a Subdirectory

You can optionally specify a subdirectory against which to search for external build systems, include directories, source files, and the like:

      path: src/some/dir/where/everything/really/is

External Build Systems

package:build_native can automatically detect configuration and build external projects based on the following files:

  • CMakeLists.txt - if present, triggers a CMake build on the system.
  • Makefile - if present, triggers a GNU make build (nmake on Windows).
  • configure - if present, it is executed via sh, followed by a make build (nmake on Windows).
  • or - if present, triggers autoreconf, configure, then make (nmake on Windws).

You can specify a target in your dependency, which will be passed to make or CMake.

Note: If your aim is cross-platform builds, I personally recommend using CMake. Opting for GNU Make can easily shut out Windows users, which many libraries might not want. (Think node-gyp, which has abysmal support for Windows.)

Explicitly Linking a File

In some cases, especially when using an external build system, a dependency might emit a shared library; in such a case, the OS needs to know where to find it. package:build_native is not able to discern this automatically, so specify the names of any possible dynamic libraries the external build might create:

    git: ...
      - libmysqlcppconnector8.1.dylib
      - libmysqlcppconnector8.1.dll

Disabling Automatic Builds

In the case that you don't want to automatically to auto-detect build configuration in an external project, make sure you pass a sources array to its configuration.

Note: You can pass ["none"], and no sources will be built, as well as disabling auto-build.

From the Web

To require an archive from the Internet:

    # All of these formats are supported:
    md5: "some-hash-here" # Recommended if distributing on Pub, for security reasons.
    sha256: SHA256 hashes are also supported

From Git

To require from Git:

      commit: "some-hash"
      branch: master
      tag: some tag
      path: foo/bar
        - include
        - src/main.c
        - src/b/c/d.c

Always cloned with --depth 1.


Save yourself a hassle by running the build within the Visual Studio Developer Command Prompt.

Regardless, executables like cl.exe and link.exe should be available. Otherwise:

To enable a 64-bit toolset:

vcvarsall might be contained in: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build


On Unix, if you some error like this:

fatal error: bits/c++config.h: No such file or directory

Then run:

sudo apt-get install -y gcc-multilib g++-multilib


  • Cover a case where file modes in an archive are null.


  • Fix decoding of .lz/.xz.


  • Resolve third party link directories against the build directory.


  • Don't build shared libraries to /dev/stdout, but to a file instead.


  • Allow malformed UTF8 sequences.


  • Patch a bug in how 3rd-party dependencies with sources were compiled.


  • Support autoconf, and check for it in doctor.
  • Check for cmake.
  • When using libraries from a 3rd-party dependency, pass the library's directory as an -L flag.


  • Build external dependencies into a separate third_party_build dir.


  • 644 => 420 in decimal...


  • Only chmod files without mode 644.
  • Support SHA1 hashes.


  • Re-enable builder.


  • Use C++ 11 on Unix systems.
  • Support decompression of .xz and .lz via package:lzma.
  • Support SHA256 checksum verification.


  • Use otool and install_name_tool to ensure that output libraries on MacOS know where to find dependencies.


  • Fix a bug in which third-party includes were not processed.


  • Don't manually git checkout if no branch/tag/commit is specified.
  • Change third_party deps from package|x -> package.x; this seems to appease CMake.


  • Log every program execution in [CONFIG].


  • Fix a small bug in how platform-specific options were discovered.


  • thirdPartyBuilder and libraryBuilder should only access the master build file.


  • Errors in doctor should print in red!


  • Added command-line utilities, for an easier experience.


  • Allow third-party libraries with sources to build their own static libraries.
  • Allow linking against the outputs of other packages.
  • Allow including headers from other packages.
  • Allow projects to explicitly disallow platforms.


  • Update the README, etc. to reflect on the fact that we are no longer using CMake.
  • Added the thirdPartyBuilder, which enables users to pull in external sources.
  • Enabled includes and linking against third_party dependencies.


  • Return to using the user's system to build object files. Hooray for incremental builds!
  • Split out object file-building functionality into a much cleaner API.


  • Update SDK constraints, dependencies, etc., to ensure the package installs!
  • Finalize decision to build to cache.


  • Use scratch_space to deal with temp files.
  • Split into build_native and example.
  • Use CMake.


  • Build individual object files separately.
  • Use a config-based approach to link libraries.
  • Windows support is now broken, but will be added again soon.

Use this package as an executable

1. Install it

You can install the package from the command line:

$ pub global activate build_native

2. Use it

The package has the following executables:

$ build_native

Use this package as a library

1. Depend on it

Add this to your package's pubspec.yaml file:

  build_native: ^0.0.10

2. Install it

You can install packages from the command line:

with pub:

$ pub get

with Flutter:

$ flutter packages get

Alternatively, your editor might support pub get or flutter packages get. Check the docs for your editor to learn more.

3. Import it

Now in your Dart code, you can use:

import 'package:build_native/build_native.dart';
Version Uploaded Documentation Archive
0.0.10 Nov 3, 2018 Go to the documentation of build_native 0.0.10 Download build_native 0.0.10 archive
0.0.9+11 Jul 5, 2018 Go to the documentation of build_native 0.0.9+11 Download build_native 0.0.9+11 archive
0.0.9+10 Jul 5, 2018 Go to the documentation of build_native 0.0.9+10 Download build_native 0.0.9+10 archive
0.0.9+9 Jul 5, 2018 Go to the documentation of build_native 0.0.9+9 Download build_native 0.0.9+9 archive
0.0.9+8 Jul 3, 2018 Go to the documentation of build_native 0.0.9+8 Download build_native 0.0.9+8 archive
0.0.9+7 Jul 3, 2018 Go to the documentation of build_native 0.0.9+7 Download build_native 0.0.9+7 archive
0.0.9+6 Jul 3, 2018 Go to the documentation of build_native 0.0.9+6 Download build_native 0.0.9+6 archive
0.0.9+5 Jul 3, 2018 Go to the documentation of build_native 0.0.9+5 Download build_native 0.0.9+5 archive
0.0.9+4 Jul 1, 2018 Go to the documentation of build_native 0.0.9+4 Download build_native 0.0.9+4 archive
0.0.9+3 Jul 1, 2018 Go to the documentation of build_native 0.0.9+3 Download build_native 0.0.9+3 archive

All 28 versions...

Describes how popular the package is relative to other packages. [more]
Code health derived from static analysis. [more]
Reflects how tidy and up-to-date the package is. [more]
Weighted score of the above. [more]
Learn more about scoring.

We analyzed this package on Dec 5, 2018, and provided a score, details, and suggestions below. Analysis was completed with status completed using:

  • Dart: 2.1.0
  • pana: 0.12.7


Detected platforms: Flutter, other

Primary library: package:build_native/build_native.dart with components: io, build.

Health issues and suggestions

Document public APIs (-10 points)

3 out of 3 API elements (library, class, field or method) have no adequate dartdoc content. Good documentation improves code readability and discoverability through search.

Fix lib/src/models/config.g.dart. (-0.50 points)

Analysis of lib/src/models/config.g.dart reported 1 hint:

line 59 col 17: Always override hashCode if overriding ==.

Fix lib/src/models/third_party.g.dart. (-0.50 points)

Analysis of lib/src/models/third_party.g.dart reported 1 hint:

line 110 col 17: Always override hashCode if overriding ==.

Format lib/src/common.dart.

Run dartfmt to format lib/src/common.dart.

Fix additional 7 files with analysis or formatting issues.

Additional issues in the following files:

  • lib/src/library_builder.dart (Run dartfmt to format lib/src/library_builder.dart.)
  • lib/src/object_file_builder.dart (Run dartfmt to format lib/src/object_file_builder.dart.)
  • lib/src/platform_type.dart (Run dartfmt to format lib/src/platform_type.dart.)
  • lib/src/read_config.dart (Run dartfmt to format lib/src/read_config.dart.)
  • lib/src/third_party/dependency_view.dart (Run dartfmt to format lib/src/third_party/dependency_view.dart.)
  • lib/src/third_party/url_dependency.dart (Run dartfmt to format lib/src/third_party/url_dependency.dart.)
  • lib/src/third_party_builder.dart (Run dartfmt to format lib/src/third_party_builder.dart.)

Maintenance suggestions

Maintain an example. (-10 points)

Create a short demo in the example/ directory to show how to use this package. Common file name patterns include: main.dart, example.dart or you could also use build_native.dart.

Package is pre-v0.1 release. (-10 points)

While there is nothing inherently wrong with versions of 0.0.*, it usually means that the author is still experimenting with the general direction of the API.


Package Constraint Resolved Available
Direct dependencies
Dart SDK >=2.0.0-dev <3.0.0
angel_serialize ^2.0.0 2.1.0
archive ^2.0.0 2.0.4
args ^1.0.0 1.5.1
build ^1.0.0 1.0.1
build_config ^0.3.0 0.3.1+4
cli_util ^0.1.3 0.1.3+2
collection ^1.0.0 1.14.11
convert ^2.0.0 2.0.2
crypto ^2.0.0 2.0.6
front_end ^0.1.2 0.1.6+8 0.1.7
io ^0.3.0 0.3.3
lzma ^0.4.0 0.4.0+2
path ^1.0.0 1.6.2
quiver ^2.0.0 2.0.1
recase ^2.0.0 2.0.0+1
scratch_space ^0.0.3 0.0.3+2
source_span ^1.0.0 1.4.1
system_info ^0.1.0 0.1.0
yaml ^2.0.0 2.1.15
Transitive dependencies
analyzer 0.33.6 0.34.0
async 2.0.8
charcode 1.1.2
csslib 0.14.6
file_utils 0.1.1
fixnum 0.10.9
glob 1.1.7
globbing 0.2.0
html 0.13.3+3
json_annotation 2.0.0
kernel 0.3.6+8 0.3.7
logging 0.11.3+2
matcher 0.12.4
meta 1.1.6
package_config 1.0.5
pedantic 1.3.0
plugin 0.2.0+3
pool 1.3.6
pub_semver 1.4.2
pubspec_parse 0.1.2+3
quiver_hashcode 2.0.0
stack_trace 1.9.3
string_scanner 1.0.4
typed_data 1.1.6
utf 0.9.0+5
watcher 0.9.7+10
Dev dependencies
angel_serialize_generator ^2.0.0
build_runner ^1.0.0