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

Overview

scikit-build

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
https://img.shields.io/pypi/dm/scikit-build

Build Status

GitHub Actions Azure
https://dev.azure.com/scikit-build/scikit-build/_apis/build/status/scikit-build.scikit-build?branchName=master

Overall Health

Requirements Status

Miscellaneous

Comments
  • 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.

    TODO

    • [ ] 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.

    Summary

    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.

    Testing

    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 setup.py install --build-type=Release
    python setup.py install --build-type=Debug
    
    # Tests that use CYTHON_FLAGS to manually specify options that retain previous behavior
    python setup.py install --build-type=Release -- -DCYTHON_FLAGS="--no-docstrings"
    python setup.py 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: https://github.com/jupyter-xeus/xeus-python-wheel/pull/36

    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 setup.py for cmake projects? Is there some example how to use it?

    Here is the setup.py that we use in csympy (cmake C++ project with optional thin Python wrappers): https://github.com/sympy/csympy/blob/c9d29e5ced2089934d769115e3002a5f0be089bc/setup.py

    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 setup.py only calls it. Currently we need to test a separate installation mechanism that setup.py 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/cmake.py 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. https://wiki.python.org/moin/WindowsCompilers).

    Tested on in pybind11's scikit_build_example example repository:

    • https://github.com/YannickJadoul/scikit_build_example/actions/runs/458497089
    • https://github.com/YannickJadoul/scikit_build_example/actions/runs/458500361

    Note in particular the removal ilammy/[email protected] action in https://github.com/YannickJadoul/scikit_build_example/commit/2c3480a01e971b1d6b460f6287d0215fee088ca1, 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: https://github.com/conda-forge/staged-recipes/pull/533

    The exact error is at https://ci.appveyor.com/project/conda-forge/staged-recipes/build/1.0.2118/job/t2axdaotmty35j6k#L216

    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: https://github.com/conda/conda-build/blob/master/appveyor.yml#L71-L74

    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
  • Shared library installs in wrong place when using nested package (package_dir)

    Shared library installs in wrong place when using nested package (package_dir)

    I'm trying to add python bindings to an existing cmake based project. I cannot share my project; however, I've managed to reproduce the problem using a modified version of the 'hello-cpp' example. The problem I'm having is that the dynamic library ends up not being copied - or ends up in the wrong place when doing a pip install.

    To reproduce (ubuntu 22.04):

    unzip nested_test.zip
    cd nested_test/
    python -m venv env
    source env/bin/activate
    pip install -v . 
    
    

    The installation seems to work, but looking more closely the package is not usable. the .so file ends up in the env/hello directory - not in the env/lib/python3.*/site-packages/hello directory ...

    I've been trying the approach mentioned here: https://stackoverflow.com/questions/70044257/packaging-executable-shared-library-and-python-bindings-not-finding-library - with no luck.

    if I change the setup.py file from package_dir = {'': 'nested/hello-cpp'},

    to

    package_dir = {'hello': 'nested/hello-cpp'},

    then things look even worse. It seems that scikit-build doesn't like that the package directory is nested (via 'package_dir')

    Any pointers to what I might be doing wrong or possible workarounds are much appreciated.

    nested_test.zip

    opened by jakobhu 0
  • cmake_minimum_required_version not parsed correctly

    cmake_minimum_required_version not parsed correctly

    I have

    from skbuild import setup
    
    setup(
        ...
        cmake_minimum_required_version="3.13...3.21",
    )
    

    which has always worked, up to now.

    Which 0.16.3 I get:

      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/home/tdegeus/data/prog/src/prrng/setup.py", line 11, in <module>
          setup(
        File "/home/tdegeus/miniforge3/envs/code_line_jed/lib/python3.11/site-packages/skbuild/setuptools_wrap.py", line 615, in setup
          if parse_version(cmkr.cmake_version) < parse_version(cmake_minimum_required_version):
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        File "/home/tdegeus/miniforge3/envs/code_line_jed/lib/python3.11/site-packages/packaging/version.py", line 52, in parse
          return Version(version)
                 ^^^^^^^^^^^^^^^^
        File "/home/tdegeus/miniforge3/envs/code_line_jed/lib/python3.11/site-packages/packaging/version.py", line 197, in __init__
          raise InvalidVersion(f"Invalid version: '{version}'")
      packaging.version.InvalidVersion: Invalid version: '3.13...3.21'
    
    opened by tdegeus 3
Releases(0.16.4)
  • 0.16.4(Dec 16, 2022)

    This releases backports additions for Windows ARM cross-compiling via cibuildwheel from scikit-build-core 0.1.4.

    • Initial experimental support for Windows ARM cross-compile in #824 and #818
    • Replace mailing list with GitHub Discussions board in #823
    • Some CI updates in #811 and #812

    Full Changelog: https://github.com/scikit-build/scikit-build/compare/0.16.3...0.16.4

    Source code(tar.gz)
    Source code(zip)
  • 0.16.3(Dec 1, 2022)

    This release fixes logging issues using setuptools 65.6+ affecting our tests. Pytest 7.2+ is now supported. setup.py <command> and setup_requires are deprecated, and tests are marked as such.

    • Fix typo in usage.rst in #795, thanks to @chohner.
    • Support pytest 7.2+ in #801.
    • Change warning filtering in #802.
    • Handle logging changes in setuptools 65.6+ in #807.
    • Add deprecated markers to some tests in #807.
    • Allow known warnings to show up in the tests #807.

    New Contributors

    • @chohner made their first contribution in https://github.com/scikit-build/scikit-build/pull/795

    Full Changelog: https://github.com/scikit-build/scikit-build/compare/0.16.2...0.16.3

    Source code(tar.gz)
    Source code(zip)
  • 0.16.2(Nov 4, 2022)

  • 0.16.1(Oct 29, 2022)

    This was a quick patch release that fixed a missing Python requires setting and some missing files #790, and addressed a warning from setuptools in the tests.

    • Ignored distutils warning #785. Thanks to @bnavigator!
    Source code(tar.gz)
    Source code(zip)
  • 0.16.0(Oct 29, 2022)

    This release adds support for Python 3.11 and removes support for Python 2.7 and 3.5 (#688). Testing and static checking improved, including being fully statically typed internally (though setuptools is not fully typed, so it is of limited use).

    All deprecated setuptools/distutils features are also deprecated in scikit-build, like the test command, easy_install, etc. Editable mode is still unsupported. Python 3.6 support is deprecated. Older versions of CMake (<3.15) are not recommended; a future version will remove support for older CMake's (along with providing a better mechanism for ensuring a proper CMake is available). If you need any of these features, please open or find an issue explaining what and why you need something.

    New Features

    • Cython module now supports FindPython mode. #743
    • PyPy is discovered without extra settings in FindPython mode #744

    Bug fixes

    • FindPython mode uses a new path specification, should help make it usable. #774
    • Better flushing and output streams for more consistent output ordering. #781
    Source code(tar.gz)
    Source code(zip)
  • 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 setup.py. 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.

    Internal

    • 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 setup.py) 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.

    Documentation

    • 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.

    Tests

    • 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 MANIFEST.in. 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 setup.py. 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 MANIFEST.in 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.

    Tests

    • 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 skbuild.platform_specifics.windows.CMakeVisualStudioCommandLineGenerator used in skbuild.platform_specifics.windows.WindowsPlatform.
      • 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.

    Documentation

    Cleanups

    • 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.

    Documentation

    • 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/__init__.py and a module fooConfig.py, and only package foo was listed in setup.py, fooConfig.py is not installed anymore.
    • CMake module targetLinkLibrariesWithDynamicLookup: Fix the caching of dynamic lookup variables. See #240 fixed by @blowekamp.

    Requirements

    • 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.

    Documentation

    Tests

    • 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.

    Documentation

    Requirements

    • 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.

    Tests

    • 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

    Cleanups

    • 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).

    Docs

    Tests

    • 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

    Docs

    • Improvement of documentation published on http://scikit-build.readthedocs.io/en/latest/
    • Add docstrings for most of the modules, classes and functions

    Tests

    • 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: https://github.com/scikit-build/scikit-build-sample-projects

    Cleanups

    • 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 http://buck.build/. Installation Since Buck is used to buil

Facebook 8.5k Jan 7, 2023
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 400 Dec 23, 2022
a small build system with a focus on speed

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

null 8.9k Jan 5, 2023
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 57 Dec 26, 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 5 Dec 23, 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 57 Oct 13, 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 403 Jan 3, 2023
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 http://coveralls.io/. T

Joakim Söderberg 82 Jan 5, 2023
CLASS Project Generator

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

The ZeroMQ project 139 Dec 10, 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 33 Oct 11, 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 https://github.com/curl/curl 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 60 Nov 14, 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 17.5k Jan 1, 2023
A template for projects using both libPeConv and MS Detours

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

hasherezade 14 Dec 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 395 Dec 24, 2022