Improved build system generator for CPython C, C++, Cython and Fortran extensions



Improved build system generator for CPython C/C++/Fortran/Cython extensions.

Better support is available for additional compilers, build systems, cross compilation, and locating dependencies and determining their build requirements.

The scikit-build package is fundamentally just glue between the setuptools Python module and CMake.

To get started, see this example and scikit-build-sample-projects.

Latest Release

Versions Downloads

Build Status

GitHub Actions Azure

Overall Health

Requirements Status


  • Testing/Bug Fixes (2016-06-06)

    Testing/Bug Fixes (2016-06-06)

    Continues the work in #36.

    Extends the testing coverage to include the new features and demo applications introduced in #36.


    • [ ] Extend testing coverage to include the new apps and new features.
      • [x] Projects that attempt to CMake-install files outside of its designated project installation root should fail to install.
        • [x] Ideally, they should fail prior to the CMake-install step (i.e.: before any problematic files are actually installed). This will need code to determine the would-be files without the aid of the install manifest.
      • [x] Each of the sample projects should have their own tests to at least ensure that they build correctly, and that any produced applications run without issue.
      • [x] Add tests for pen2_cython
      • [x] Add tests for tower-of-babel
    • [ ] There are multiple bugs in the way command line arguments are processed and forwarded in scikit-build. It's not clear if they were introduced by these changes, or if they predate them.
      • [ ] There is a bug when trying to specify the desired CMake build type via the --build-type option in scikit-build. It seems that some sections of the code are looking for CMAKE_BUILD_DIR/CMAKE_BUILD_TYPE as the ultimate location of the cmake build directory. I think handling multiple builds in one tree is desirable and we should probably extend this handling to the other temporary staging directories, but right now, these improvements were not expecting this. We'll need to go through the various code sections and make sure everyone's on the same page.
      • [ ] On a related note, I tried to pass options directly to CMake through scikit-build using the -- argument seperator. Scikit-build is currently written to expect up to three sections of such options: the first for scikit-build options, the second for CMake config options, and the third for options to the build step. However, since CMake is used to drive the build step, options meant for the actual build tool (e.g.: make) must be separated by another -- separator. Currently scikit-build fails to properly handle this fourth separator.
    • [ ] Currently the only way to add to the Cython module search path for add_cython_target is to use the outdated include_directories CMake command. Ideally, we would be able to use target_include_directories or something similar. This may involve the creation of an actual CMake target.
    opened by opadron 85
  • [WIP] Remove sample projects/Refactor CI driver

    [WIP] Remove sample projects/Refactor CI driver

    Removes sample projects: "pen2-cython" and "tower-of-babel", in preparation for their move to their own projects repository.

    Also, refactors more of the CI testing logic into driver scripts, in preparation for moving it to its own repository.

    This PR is super WIP. I expect the changes to break all the testing at first.

    This PR should resolve or partially address #46, #63, #78 This work should likely be merged with #97

    opened by opadron 36
  • Use default Cython flags to include Cython docstrings by default.

    Use default Cython flags to include Cython docstrings by default.


    This PR changes Cython behavior to use the default arguments for embedding docstrings and source positions.

    This disables --no-docstrings in Release and MinSizeRel builds, so Cython docstrings are now retained by default. Additionally, --embed-positions is now disabled by default in Debug and RelWithDebInfo builds. Users can enable these and other Cython arguments via the option CYTHON_FLAGS. Resolves #518.


    I tested this locally, and both Release and Debug configurations show the behavior changes I expect. Release builds no longer strip docstrings, and Debug builds no longer embed positions into the docstrings. Commands tested:

    # Tests of default behavior (fixed)
    python install --build-type=Release
    python install --build-type=Debug
    # Tests that use CYTHON_FLAGS to manually specify options that retain previous behavior
    python install --build-type=Release -- -DCYTHON_FLAGS="--no-docstrings"
    python install --build-type=Debug -- -DCYTHON_FLAGS="--embed-positions"
    opened by bdice 28
  • Add hook to process manifest

    Add hook to process manifest

    This is a simple hook to enable custom processing of the cmake manifest before producing the wheel.

    The goal for us is to drop static binaries of dependencies, as well as their headers, and other artefacts such as cmake files, as we want the wheel to only include what is required at runtime.

    I am using this here:

    Fixes #473

    Type: Enhancement 
    opened by SylvainCorlay 26
  • Can no longer build on macOS

    Can no longer build on macOS

    macOS anaconda builds seem to have been broken at some point after scikit build 0.6 or so, or maybe on upgrading to macOS 10.13, I'm not sure which. I now get the error:

    clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
          ld: library not found for -lstdc++
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

    I believe as of here this is now forced to be 10.6 which breaks the compiler.

    Edit: Broken on homebrew Python too.

    Edit 2: This works correctly on Scikit-build 0.6.1 on the current macOS.

    Status: Awaiting Response :hourglass_flowing_sand: 
    opened by henryiii 26
  • Add docs how to use the package

    Add docs how to use the package

    Is the goal of this package to create robust for cmake projects? Is there some example how to use it?

    Here is the that we use in csympy (cmake C++ project with optional thin Python wrappers):

    It works, but I would prefer to actually install the Python wrappers/package using make install from cmake (which is well tested in our project). That way we just make sure that make install works, and only calls it. Currently we need to test a separate installation mechanism that uses.

    Type: Docs 
    opened by certik 24
  • docs: use moderncmakedomain, Sphinx 4

    docs: use moderncmakedomain, Sphinx 4

    This enables the use of Sphinx 4. The copy of docs/ from CMake has been replaced with sphinxcontrib-moderncmakedomain, which is a port of that file to PyPI, and is much more up-to-date (from CMake 3.19, whereas our copy was much other and didn't support Sphinx 4). Really, it seems like something like that could be maintained as part of scikit-build; curious to know @slurps-mad-rips's opinion on that. We use sphinxcontrib-moderncmakedomain in pybind11.

    This also pins docutils, as docutils 0.17 is not compatible with sphinx-rtd-theme currently. I'd really like to move away from the rtd theme for this and other reasons.

    Requested in #573.

    opened by henryiii 23
  • Support Visual Studio 2019

    Support Visual Studio 2019

    On GitHub Actions' windows-latest image VS 2019 is available, but not detected by scikit-build. Python >= 3.5 can be built by VS 2019, though (cfr.

    Tested on in pybind11's scikit_build_example example repository:


    Note in particular the removal ilammy/[email protected] action in, which masked/worked around the failure to detect VS 2019.

    Fixes #496.

    (CC @henryiii)

    opened by YannickJadoul 19
  • Finding Visual C++ compiler for Python with CMake (on appveyor)

    Finding Visual C++ compiler for Python with CMake (on appveyor)

    Greetings, this is a copy of a message I posted to the cmake mailing list, but got no love there. Since you all are closer to this topic, I hope you might know something helpful.

    In compiling TBB, a conda-forge contributor ran across issues with CMake not finding the VS compiler for VS 2008 Win64:

    The exact error is at

    Appveyor is an interesting platform, in that they install VS 2008 Express, then the VS compiler for Python (which adds the 64-bit compilation support).

    I have been able to fix this in conda-build's test suite by adding some extra registry information and copying some files:

    Is our version of cmake too old? Is there some other way we can teach CMake to look in the right place, so that that ugly hack of editing the registry is not necessary?

    Type: Enhancement Category: Tests 
    opened by msarahan 19
  • Python library not found when using recent setuptools with pypy

    Python library not found when using recent setuptools with pypy

    It seems like there is a problem using pypy 7.3.7 together with scikit-build and setuptools version 64.2.0 because cmake is called with -DPYTHON_LIBRARY=. Using the setuptools version 59.4.0, everything works and a correct library path is passed. Does anyone know about this problem?

    I originally reported the problem in the manylinux project pypa/manylinux#1246 where I also attached log files.

    opened by rkaminsk 18
  • fix: support and always call MSVC with -A

    fix: support and always call MSVC with -A

    This takes just the non-2019 changes out of #526. Should make it easier to debug the issue with the failure there.

    (pass through architecture, and test fixes)

    opened by henryiii 16
  • Consider using to Find Python introduced in cmake 3.12

    Consider using to Find Python introduced in cmake 3.12

    Code like the one referneced above in master as of August uses the old syntax of Find Python. In cmake 3.12, a new syntax was introduced to help finding a consistent environment between python and numpy headers.

    This also introduced better support for pypy.

    The downside is that this new feature

    Depends on cmake 3.12 released in 2018.

    Would you accept to modernize the cmake files? It seems that a few downstream projects, like zfpy would benefit from this change when compiling for pypy.

    opened by hmaarrfk 1
  • How to specify `-j ${PARALLEL_LEVEL}` for both cmake and wheel

    How to specify `-j ${PARALLEL_LEVEL}` for both cmake and wheel


    In a mixed Cpp + Python project, pre-scikit-build, I would run the following commands to get its CPP and Python components built with a given PARALLEL_LEVEL:

    # from cpp source code
    cmake -DOPT1=VAL1 -DOPT2=VAL2 ...
    cmake --build -j${PARALLEL_LEVEL} ...
    # for python wheel build
    python bdist_ext -j${PARALLEL_LEVEL}

    I'm looking for replacements, when using scikit-build:

    • I have tried setting the environment variable CMAKE_BUILD_PARALLEL_LEVEL, seemingly without much effect
    • I'm also looking for ways to specify it for the Python wheel build when using different wheel building frontends, not manually specifying commands
    opened by sevagh 2
  • pip 22.2 does not support install options anymore

    pip 22.2 does not support install options anymore

    pip3 install . --user -j1 --build-type Debug -- -DCODE_COVERAGE=ON
    no such option: -j

    (Any option which is not pip option is not currently supported by pip, it was working ~3 months ago. ) It should probably be mentioned in My current problem is that I can not specify "--build-type Debug", I can use export SKBUILD_CONFIGURE_OPTIONS="-DCMAKE_BUILD_TYPE:STRING=Debug" but then it gets duplicated in commands

     An error occurred while building with CMake.
          cmake --build . --target install --config Release --

    Ubuntu 22.04 LTS

    • python3.10
    • pip 22.2
    • scikit-build 0.15.0
    • setuptools 59.6.0
    opened by Nic30 0
  • chore: mypy updates

    chore: mypy updates

    This was sitting around, let's go ahead and see what the diff looks like. I was playing with monkeytype.

    • chore: update mypy settings a bit
    • chore: run monkeytype, update old workarounds

    Looks like monkey type was too specific, some need generalization. :)

    opened by henryiii 0
  • 0.15.0(May 18, 2022)

    This release is the final (again) release for Python < 3.6 and MSVC<2017. Support for FindPython from CMake 3.12+ was added, including FindPython2. Support for Cygwin added.

    New Features

    • Add support for FindPython (including 2 and 3). Thanks @hameerabbasi for the contribution. See #712.
    • Add support for Cygwin. Thanks @ax3l and @DWesl and @poikilos for the help! See #485.

    Bug fixes

    • Fixed issue with distutils usage in Python 3.10. Thanks to @SuperSandro2000 for the contribution in #700.
    Source code(tar.gz)
    Source code(zip)
  • 0.14.1(Apr 7, 2022)

    This release fixes a regression, and reverts a fix in 0.14.0. Some changes made to CI to fix recent removals.

    Bug fixes

    • Fix issue with SKBUILD_CONFIGURE_OPTIONS not being read.
    • Reverted manifest install changes.
    Source code(tar.gz)
    Source code(zip)
  • 0.14.0(Apr 4, 2022)

    This is the final release for Python <3.6 and MSVC<2017.

    New Features

    • Add support for --install-target scikit-build command line option. And cmake_install_target in Allows providing an install target different than the default install. Thanks @phcerdan for the contribution. See #477.

    Bug fixes

    • The manifest install location computation was fixed. Thanks @kratsg for the contribution in #682.
    • Byte-compilation was skipped due to a missing return. Thanks @pekkarr in #678.
    • Packages can now be computed from the same shared collections, before this could confuse Scikit-build. Thanks @vyasr in #675.
    • Fixed library detection for PyPy 3.9. Thanks @rkaminsk in #673.


    • Scikit-build now uses pyproject.toml and setuptools_scm to build. If you are packaging scikit-build itself, you might need to update your requirements. See #634.
    • The codebase is now formatted with Black. #665
    Source code(tar.gz)
    Source code(zip)
  • 0.13.1(Feb 7, 2022)

    This release fixes two bugs affecting Windows. Users should use "ninja; platform_system!='Windows'", at least for now, since MSVC ships with Ninja, and that Ninja is better at finding the matching MSVC than the Python package is. Including it may slow down the search and force the IDE generator instead, but will at least no longer discover GCC instead.

    Bug fixes

    • On Windows, don't let Ninja find something other than what it's supposed to look for. Ensure the Ninja package is used for the search, just like normal runs, if installed. #653
    • Do not throw an error when printing info and a logger is disconnected. #652
    Source code(tar.gz)
    Source code(zip)
  • 0.13.0(Feb 2, 2022)

    This is likely one of the final releases to support Python 2.7 and 3.5; future releases will likely target at least Python 3.6+ and MSVC 2017+.

    If you are using scikit-build via pyproject.toml, please remember to include setuptools and wheel. A future version of scikit-build may remove the setuptools install-time hard requirement.

    New Features

    • CMake module /cmake-modules/Cython now uses Cython default arguments. This no longer adds --no-docstrings in Release and MinSizeRel builds, so Cython docstrings are now retained by default. Additionally, --embed-positions is no longer added to Debug and RelWithDebInfo builds. Users can enable these and other Cython arguments via the option CYTHON_FLAGS. See #518 and #519, thanks to @bdice for the improvement.
    • Experimental support for ARM64 on Windows. Thanks to @gaborkertesz-linaro in #612.
    • Support for MSVC 2022. Thanks to @tttapa for the contribution in #627.
    • Support the modern form of target_link_libraries, via SKBUILD_LINK_LIBRARIES_KEYWORD (somewhat experimental). Thanks to @maxbachmann in #611.

    Bug fixes

    • Update the Ninja path if using the ninja package. This fixes repeated isolated builds. Further path inspection and updates for isolated builds may be considered in the future. #631, thanks to @RUrlus and @segevfiner for help in tracking this down.
    • Allow OpenBSD to pass the platform check (untested). See #586.
    • Avoid forcing the min macOS version. Behaviour is now inline with setuptools. Users should set MACOSX_DEPLOYMENT_TARGET when building (automatic with cibuildwheel), otherwise you will get the same value Python was compiled with. Note: This may seem like a regression for PyPy until the next release (7.3.8), since it was compiled with 10.7, which is too old to build with on modern macOS - manually set MACOSX_DEPLOYMENT_TARGET (including setting it if unset in your for PyPy until 7.3.8. #607
    • Fix logging issue when using Setuptools 60.2+. #623
    • MacOS cross compiling support fix (for conda-forge) for built-in modules. Thanks to @isuruf for the contribution in #622.
    • Better detection of the library path, fixes some issues with PyPy. Thanks to @rkaminsk for the contribution in #620 and #630. PyPy is now part of our testing matrix as of #624. Also @robtaylor in #632.
    • Fixed issue when cross-compiling on conda-forge (probably upstream bug, but easy to avoid). #646.
    Source code(tar.gz)
    Source code(zip)
  • 0.12.0(Aug 11, 2021)

    The scikit-build GitHub organization welcomes henryiii and mayeut as core contributors and maintainers. Both are also maintainers of cibuildwheel.

    @henryiii is a pybind11 and pypa/build maintainer, has been instrumental in adding Apple Silicon support, adding support for Visual Studio 2019, updating the Continuous Integration infrastructure, as well as helping review & integrate contributions, and addressing miscellaneous issues. Additionally, henryiii has worked on an example project to build with pybind11 and scikit-build.

    @mayeut is a manylinux maintainer and focused his effort on updating the cmake-python-distributions and ninja-python-distributions so that the corresponding wheels are available on all supported platforms including Apple Silicon and all flavors of manylinux.

    New Features

    • Support Apple Silicon, including producing Universal2 wheels (#530) and respecting standard setuptools cross-compile variables (#555). Thanks to @YannickJadoul for the contributions.
    • Support MSVC 2019 without having to run it with the MSVC activation variables, just like 2017 and earlier versions. Thanks to @YannickJadoul for the contribution in #526.

    Bug fixes

    • Support -A and -T internally when setting up MSVC generators. Architecture now always passed through -A to MSVC generators. Thanks @YannickJadoul for the contribution. See #557 and #536.
    • Fixed a regression that caused setuptools to complain about unknown setup option (cmake_process_manifest_hook). Thanks @Jmennius for the contribution. See #498.
    • If it applies, ensure generator toolset is used to configure the project. Thanks @YannickJadoul for the contributions. See #526.
    • Read CYTHON_FLAGS where needed, instead of once, allowing the user to define multiple modules with different flags. Thanks @oiffrig for the contributions in #536.
    • Avoid an IndexError if prefix was empty. Thanks @dfaure for the contributions in #522.


    • Update Conda: Step-by-step release guide available in /make_a_release section.
    • Update links to CMake documentation pages in /generators. Thanks @Eothred for the contributions in #508.


    • Improve and simplify Continuous Integration infrastructure.
      • Support nox for running the tests locally. See #540.
      • Use GitHub Actions for Continuous Integration and remove use of scikit-ci, tox, TravisCI, AppVeyor and CircleCI. See #549, #551 and #552.
      • Add support for testing against Python 3.10. See #565.
      • Style checking handled by pre-commit. See #541.
      • Check for misspellings adding GitHub Actions workflow using codespell. See #541.
    • Fix linting error F522 reported with flake8 >= 3.8.x. Thanks @benbovy for the contributions. See #494.
    • Fix regex in tests to support Python 3.10. Thanks @mgorny for the contributions in #544.
    Source code(tar.gz)
    Source code(zip)
  • 0.11.1(Jun 10, 2020)

  • 0.11.0(Jun 10, 2020)

  • 0.10.0(May 23, 2019)

  • 0.9.0(Mar 5, 2019)

  • 0.8.1(Oct 3, 2018)

  • 0.8.0(Oct 3, 2018)

  • 0.7.1(Oct 3, 2018)

  • 0.7.0(Oct 3, 2018)

    Scikit-build 0.7.0

    New Features

    • Faster incremental build by re-configuring the project only if needed. This was achieved by (1) adding support to retrieve the environment mapping associated with the generator set in the CMakeCache.txt file, (2) introducing a CMake spec file storing the CMake version as well as the the CMake arguments and (3) re-configuring only if either the generator or the CMake specs change. Thanks @xoviat for the contribution. See #301.
    • CMake modules:
      • CMake module PythonExtensions: Set symbol visibility to export only the module init function. This applies to GNU and MSVC compilers. Thanks @xoviat. See #299.
      • Add CMake module F2PY useful to find the f2py executable for building Python extensions with Fortran. Thanks to @xoviat for moving forward with the integration. Concept for the module comes from the work of @scopatz done in PyNE project. See #273.
      • Update CMake module NumPy setting variables NumPy_CONV_TEMPLATE_EXECUTABLE and NumPy_FROM_TEMPLATE_EXECUTABLE. Thanks @xoviat for the contribution. See #278.
    • Setup keywords:
      • Add support for cmake_languages setup keyword.
      • Add support for include_package_data and exclude_package_data setup keywords as well as parsing of See #315. Thanks @reiver-dev for reporting the issue.
      • Add support for cmake_minimum_required_version setup keyword. See #312. Suggested by @henryiii.
      • Install cmake if found in setup_requires list. See #313. Suggested by @henryiii.
    • Add support for --cmake-executable scikit-build command line option. Thanks @henryborchers for the suggestion. See #317.
    • Use _skbuild/platform-X.Y instead of _skbuild to build package. This allows to have a different build directory for each python version. Thanks @isuruf for the suggestion and @xoviat for contributing the feature. See #283.
    • Run cmake and develop command when command test is executed.

    Bug fixes

    • Fix support of --hide-listing when building wheel.
    • CMake module Cython: Fix escaping of spaces associated with CYTHON_FLAGS when provided as command line arguments to the cython executable through CMake cache entries. See #265 fixed by @neok-m4700.
    • Ensure package data files specified in the setup() function using package_data keyword are packaged and installed.
    • Support specifying a default directory for all packages not already associated with one using syntax like package_dir={'':'src'} in Thanks @benjaminjack for reporting the issue. See #274.
    • Improve --skip-cmake command line option support so that it can re-generate a source distribution or a python wheel without having to run cmake executable to re-configure and build. Thanks to @jonwoodring for reporting the issue on the mailing list.
    • Set skbuild <version> as wheel generator. See PEP-0427 and #191.
    • Ensure is considered when generating source distribution. Thanks @seanlis for reporting the problem and providing an initial patch, and thanks @henryiii for implementing the corresponding test. See #260.
    • Support generation of source distribution for git repository having submodules. This works only for version of git >= 2.11 supporting the --recurse-submodules option with ls-files command.

    Internal API

    Python Support

    • Tests using Python 3.3.x were removed and support for this version of python is not guaranteed anymore. Support was removed following the deprecation warnings reported by version 0.31.0 of wheel package, these were causing the tests test_source_distribution and test_wheel to fail.


    • Speedup execution of tests that do not require any CMake language enabled. This is achieved by (1) introducing the test project hello-no-language, (2) updating test utility functions execute_setup_py and project_setup_py_test to accept the optional parameter disable_languages_test allowing to skip unneeded compiler detection in test project used to verify that the selected CMake generator works as expected, and (3) updating relevant tests to use the new test project and parameters.

      Overall testing time on all continuous integration services was reduced:

      • AppVeyor:
        • from ~16 to ~7 minutes for 64 and 32-bit Python 2.7 tests done using Visual Studio Express 2008
        • from more than 2 hours to ~50 minutes for 64 and 32-bit Python 3.5 tests done using Visual Studio 2015. Improvement specific to Python 3.x were obtained by caching the results of slow calls to distutils.msvc9compiler.query_vcvarsall (for Python 3.3 and 3.4) and distutils._msvccompiler._get_vc_env (for Python 3.5 and above). These functions were called multiple times to create the list of used in
      • CircleCI: from ~7 to ~5 minutes.
      • TravisCI: from ~21 to ~10 minutes.
    • Update maximum line length specified in flake8 settings from 80 to 120 characters.

    • Add prepend_sys_path utility function.

    • Ensure that the project directory is prepended to sys.path when executing test building sample project with the help of execute_setup_py function.

    • Add codecov config file for better defaults and prevent associated Pull Request checks from reporting failure when coverage only slightly changes.



    • Fix miscellaneous pylint warnings.
    Source code(tar.gz)
    Source code(zip)
  • 0.6.1(Jun 8, 2017)

    Scikit-build 0.6.1

    Bug fixes

    • Ensure CMake arguments passed to scikit-build and starting with -DCMAKE_* are passed to the test project allowing to determine which generator to use. For example, this ensures that arguments like -DCMAKE_MAKE_PROGRAM:FILEPATH=/path/to/program are passed. See #256.


    • Update Making a release section including instructions to update README.rst with up-to-date pypi download statistics based on Google big table.
    Source code(tar.gz)
    Source code(zip)
    scikit-build-0.6.1.tar.gz(81.34 KB)
    scikit-build-0.6.1.tar.gz.asc(819 bytes)
    scikit_build-0.6.1-py2.py3-none-any.whl(51.68 KB)
    scikit_build-0.6.1-py2.py3-none-any.whl.asc(819 bytes)
  • 0.6.0(Feb 16, 2017)

    Scikit-build 0.6.0

    New features

    • Improve py_modules support: Python modules generated by CMake are now properly included in binary distribution.
    • Improve developer mode support for py_modules generated by CMake.

    Bug fixes

    • Do not implicitly install python modules when the beginning of their name match a package explicitly listed. For example, if a project has a package foo/ and a module, and only package foo was listed in, is not installed anymore.
    • CMake module targetLinkLibrariesWithDynamicLookup: Fix the caching of dynamic lookup variables. See #240 fixed by @blowekamp.


    • wheel: As suggested by @thewtex, unpinning version of the package by requiring >=0.29.0 instead of ==0.29.0 will avoid uninstalling a newer version of wheel package on up-to-date system.



    • Extend test_hello, test_setup, and test_sdist_hide_listing to (1) check if python modules are packaged into source and wheel distributions and (2) check if python modules are copied into the source tree when developer mode is enabled.

    Internal API

    Source code(tar.gz)
    Source code(zip)
    scikit-build-0.6.0.tar.gz(79.81 KB)
    scikit-build-0.6.0.tar.gz.asc(819 bytes)
    scikit_build-0.6.0-py2.py3-none-any.whl(51.32 KB)
    scikit_build-0.6.0-py2.py3-none-any.whl.asc(819 bytes)
  • 0.5.1(Dec 23, 2016)

  • 0.5.0(Dec 22, 2016)

    Scikit-build 0.5.0

    New features

    Bug fixes

    • Fix scikit-build source distribution and add test. See #214 Thanks @isuruf for reporting the issue.
    • Support building extension within a virtualenv on windows. See #119.



    • setuptools: As suggested by @mivade in #212, remove the hard requirement for ==28.8.0 and require version >= 28.0.0. This allows to “play” nicely with conda where it is problematic to update the version of setuptools. See pypa/pip#2751 and ContinuumIO/anaconda-issues#542.


    • Improve “push_dir” tests to not rely on build directory name. Thanks @isuruf for reporting the issue.
    • travis/install_pyenv: Improve MacOSX build time updating scikit-ci-addons
    • Add get_cmakecache_variables utility function.

    Internal API


    • appveyor.yml:
    • Remove unused “on_failure: event logging” and “notifications: GitHubPullRequest”
    • Remove unused SKIP env variable
    Source code(tar.gz)
    Source code(zip)
    scikit-build-0.5.0.tar.gz(74.40 KB)
    scikit_build-0.5.0-py2.py3-none-any.whl(50.31 KB)
  • 0.4.0(Oct 31, 2016)

    Scikit-build 0.4.0 Release Notes

    Updates since 0.3.0

    • Do not package python modules under "purelib" dir in non-pure wheel
    • Add support for --hide-listing option
      • allow to build distributions without displaying files being included
      • useful when building large project on Continuous Integration service limiting the amount of log produced by the build.

    CMake modules

    • skbuild/resources/cmake/FindPythonExtensions.cmake
      • Function python_extension_module: add support for module suffix
    • skbuild/resources/cmake/targetLinkLibrariesWithDynamicLookup.cmake:
      • Fix the logic checking for cross-compilation (the regression was introduced by scikit-build/scikit-build#51 and scikit-build/scikit-build#47
      • It configure the text project setting CMAKE_ENABLE_EXPORTS to ON. Doing so ensure the executable compiled in the test exports symbols (if supported by the underlying platform).



    • tests/samples: Simplify project removing unneeded install rules and file copy
    • Simplify continuous integration
    • Makefile:
      • Fix coverage target
      • Add docs-only target allowing to regenerator the Sphinx documentation without opening a new page in the browser.
    Source code(tar.gz)
    Source code(zip)
    scikit-build-0.4.0.tar.gz(50.30 KB)
    scikit_build-0.4.0-py2.py3-none-any.whl(44.89 KB)
  • 0.3.0(Sep 20, 2016)

    Scikit-build 0.3.0 Release Notes

    Updates since 0.2.0

    • Fix dispatch of arguments to setuptools, CMake and build tool (#118)
    • Improve support for "pure", "CMake" and "hybrid" python package
      • a "pure" package is a python package that have all files living in the project source tree
      • an "hybrid" package is a python package that have some files living in the project source tree and some files installed by CMake
      • a "CMake" package is a python package that is fully generated and installed by CMake without any of his files existing in the source tree
    • Force binary wheel generation (#106)
    • Add support for source distribution (#84)
    • Add support for setup arguments specific to scikit-build:
      • cmake_args: additional option passed to CMake
      • cmake_install_dir: relative directory where the CMake project being built should be installed
      • cmake_source_dir: location of the CMake project
    • Fix support for py_modules (6716723)
    • Add CMake module FindNumPy.cmake
    • Automatically set package_dir to reasonable defaults
    • Support building project without CMakeLists.txt
    • Do not raise error if calling "clean" command twice


    • Improvement of documentation published on
    • Add docstrings for most of the modules, classes and functions


    • Ensure each test run in a dedicated temporary directory
    • Add tests to raise coverage from 70% to 91%
    • Refactor CI testing infrastructure introducing CI drivers written in python for AppVeyor, CircleCI and TravisCI
    • Switch from nose to py.test
    • Relocate sample projects into a dedicated home:


    • Refactor commands introducing set_build_base_mixin and new_style
    • Remove unused code
    Source code(tar.gz)
    Source code(zip)
    scikit-build-0.3.0.tar.gz(59.72 KB)
    scikit_build-0.3.0-py2.py3-none-any.whl(41.80 KB)
A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.

Buck Buck is a build tool. To see what Buck can do for you, check out the documentation at Installation Since Buck is used to buil

Facebook 8.4k Aug 10, 2022
Tundra is a code build system that tries to be accurate and fast for incremental builds

Tundra, a build system Tundra is a high-performance code build system designed to give the best possible incremental build times even for very large s

Andreas Fredriksson 372 Jul 17, 2022
a small build system with a focus on speed

Ninja Ninja is a small build system with a focus on speed. See the manual or doc/manual.asciidoc included in the distribution

null 8.4k Aug 9, 2022
muon is an implementation of the meson build system in C with minimal dependencies.

muon muon is an implementation of the meson build system in C with minimal dependencies. Non-features bug-for-bug compatibility with meson. In fact, m

Stone Tickle 39 Aug 8, 2022
A basic build system for the Skript scripting language.

skib A basic build system for the Skript scripting language. Features #include other files recursively #define preprocessor symbols and macros Usage #

Daniel 1 Jun 27, 2022
NeoWorld is a resampler using the CMake build system

NeoWorld is a resampler using the CMake build system. It's designed for utsu, OpenUTAU, and UTAU.

null 4 Jun 24, 2022
Arduino CMake Build system

Arduino Cmake Example Project This is the Cmake project settings for the Arduino platform. You can use this project as an example to develop C++ progr

Francois Campbell 55 May 23, 2022
An Enhancement Suite for the CMake Build System

A CMake Enhancement Suite Usage Look through the files in the package. Most functions will be commented and the other's usage can be inferred. All fun

Tobias Becker 397 Aug 5, 2022
Coveralls JSON coverage generator and uploader for CMake

Coveralls Generator for CMake This is a set of CMake scripts that are meant to be used to generate and upload coverage data to T

Joakim Söderberg 82 Aug 8, 2022
CLASS Project Generator

zproject - CLASS Project Generator Contents Overview Scope and Goals Tutorial Installation Getting started Setup your project environment Configuratio

The ZeroMQ project 135 Jan 11, 2022
Yet another post-build step and class to bring reflection to C++ enumerations.

enum_values Yet another post-build step and class to bring reflection to C++ enumerations! Fair warning: this project has not undergone much testing (

null 12 May 11, 2022
Examples of using Hunter package manager to build and run Android application.

Examples of using Hunter package manager to build and run Android application. Requirements Android NDK Go to download page and choose NDK for your pl

null 34 Mar 13, 2022
CMake and other scripts to help build process of FlyEM software

The BuildEM System The buildem repo is a modular CMake-based system that leverages CMake's ExternalProject to simplify and automate a complex build pr

null 27 Jun 9, 2022
nabs is a single-header library for writing build recipes in C++

nabs is a single-header library for writing build recipes in C++. It is directly inspired by nobuild, but with more feature (bloat) and built-in support for makefile-like dependency resolution.

zhiayang 6 May 8, 2021
curl cmake module libcurl build with msvc x86

curl-msvc Infomation curl cmake module libcurl build with MSVC10.0 arch (x86 | i386) source from tags: curl-7_79_1 Usage

Jason Payne 0 May 16, 2022
Project to enable using CMake from a Maven build.

CMake-Maven-Project Introduction A Maven project for the CMake build system. It can be used by including it as a plugin within your Maven project's po

null 58 Jul 13, 2022
C++ Library Manager for Windows, Linux, and MacOS

Vcpkg: Overview 中文总览 Español 한국어 Français Vcpkg helps you manage C and C++ libraries on Windows, Linux and MacOS. This tool and ecosystem are constant

Microsoft 16.4k Aug 5, 2022
A template for projects using both libPeConv and MS Detours

A CMake template for projects using MS Detours along with libPeConv.

hasherezade 11 Mar 16, 2022
CMake scripts for painless usage of SuiteSparse+METIS from Visual Studio and the rest of Windows/Linux/OSX IDEs supported by CMake

CMake scripts for painless usage of Tim Davis' SuiteSparse (CHOLMOD,UMFPACK,AMD,LDL,SPQR,...) and METIS from Visual Studio and the rest of Windows/Lin

Jose Luis Blanco-Claraco 385 Aug 2, 2022