The Meson Build System

Related tags

Build Tools meson
Overview

Meson® is a project to create the best possible next-generation build system.

Status

PyPI Build Status Codecov Code Quality: Python Total Alerts

Dependencies

  • Python (version 3.6 or newer)
  • Ninja (version 1.8.2 or newer)

Installing from source

Meson is available on PyPi, so it can be installed with pip3 install meson. The exact command to type to install with pip can vary between systems, be sure to use the Python 3 version of pip.

If you wish you can install it locally with the standard Python command:

python3 -m pip install meson

For builds using Ninja, Ninja can be downloaded directly from Ninja GitHub release page or via PyPi

python3 -m pip install ninja

More on Installing Meson build can be found at the getting meson page.

Running

Meson requires that you have a source directory and a build directory and that these two are different. In your source root must exist a file called meson.build. To generate the build system run this command:

meson setup <source directory> <build directory>

Depending on how you obtained Meson the command might also be called meson.py instead of plain meson. In the rest of this document we are going to use the latter form.

You can omit either of the two directories, and Meson will substitute the current directory and autodetect what you mean. This allows you to do things like this:

cd <source root>
meson setup builddir

To compile, cd into your build directory and type ninja. To run unit tests, type ninja test.

More on running Meson build system commands can be found at the running meson page or by typing meson --help.

Contributing

We love code contributions. See the contribution page on the website for details.

IRC

The irc channel for Meson is #mesonbuild over at Freenode.

You can use FreeNode's official webchat to connect to this channel.

Further info

More information about the Meson build system can be found at the project's home page.

Meson is a registered trademark of Jussi Pakkanen.

Comments
  • Set project and meson options in cross/native files

    Set project and meson options in cross/native files

    This is a partial implementation of #3001, but not everything.

    This series allows meson builtins and project options to be specified in the cross and/or native files. This should make it easier to set up subprojects in a reliable way, as all of the options can be kept in a native/cross file. With file layering a projects can even ship preconfigured options, that the end user can overlay with their own cross/native files.

    For mesa we'd like to couple this with the ability to set some builtin options (namely default_library) on a per-subproject basis to control wraps in a predictable way.

    opened by dcbaker 95
  • mtest: test output changes

    mtest: test output changes

    This is the second iteration of #9232.

    I've done my best to better split the changes into smaller commits although while doing that I ended writing even more changes.

    The changes can now be summarized:

    Changes in the textual test log output

    Test specific metadata was split to multiple lines to improve readability. Visual hints were added to group togehter all the lines related to a specifc test.

    Textual test log (too) now respects the and options.

    Changes in the test output in the console

    The way test details (when being verbose or printing details for a failed test) get printed was updated. Most notable changes are:

    • each line is prefixed with the relevant test number
    • "headers" and indentation is used to group relevant lines together
    • the style in which subtest results are listed changed

    Results of individual subtests are displaed only in verbose mode or when printing details of a failed test.

    The "live" output (when being verbose and using only one process) now follows the style of the normal verbose output more closely.

    The "live" output is now automatically used when running only one test in verbose mode.

    The statusline was updated to a multi line one. The status line is also disabled if the size of the terminal is not at least 80 characters wide and 24 rows tall.

    The status line in quiet mode was simplified.

    I made a recording where I try to demo the changes: https://asciinema.org/a/dE9DsiPzUXJcW5X0q0XyO4vQ9

    I have some concers w.r.t these changes:

    • Multiple status lines tend to "flicker" a bit when lots of lines are being outputted. Some people might find this annoying.
    • There is currently no way to disable "live" output when using only one process (though this is true even withtout these changes). I thought about adding an option for that but too may options for the command is not that great either.
    • The first iteration received feedback that the statusline is not nice on some windows terminal. I failed to reproduce this but then again my Windows skills are lacking. I tried these changes with the "command prompt for VS 2019" but didn't notice any issues there. I feel the statusline should just be disabled when using an incapable terminal (think meson test | cat) but without being able to reproduce the issue I don't quite know what to do.
    • I've only tried this out in Sourcehut's and GitLab's CI systems. Other CI sytems (Travis, Azures, ...) have not been tested at all.
    • Do other people like the change?

    I'll mark this PR as draft to avoid premature merging until the above concerns get clarified and we can get a blessing from the relevant people. I'll mention @bonzini and @anarazel here by name since they joined the discussion during the first iteration.

    opened by trhd 86
  • Fix linking of shared/static libs with static libs

    Fix linking of shared/static libs with static libs

    This commit contains the following fixes:

    1. When a shared library A does link_with: to static library B, the parts of B used by A will be added to A, and so we don't need to return B in A.get_dependencies() for targets that link to A. This already is the behaviour when a shared library A does link_whole: on B.

    2. In situation (1), when generating a pkg-config file for A, we must also not add B to Libs.private for A. This already is the behaviour when a shared library A does link_whole: on B.

    3. When a static library A does link_whole: to static library B, we must add the objects in B to A.

    4. When a static library A does link_with: to static library B, and B is not installed (which makes it an internal static library), we must add the objects in B to A, otherwise nothing can use A.

    5. In situation (4), when generating a pkg-config file for A, we must also not add B to Libs.private for A.

    All these situations are tested by the unit test added in this commit.

    Closes https://github.com/mesonbuild/meson/issues/3934 Closes https://github.com/mesonbuild/meson/issues/3937

    opened by nirbheek 62
  • macOS: add libtool compatible versioning and fix rpath issues

    macOS: add libtool compatible versioning and fix rpath issues

    This patch exploits the information residing in ltversion to set the -compatibility_version and -current_version flags that are passed to the linker on macOS.

    it also fixes well known rpath issues on macOS with the dylibs generated by meson.

    See #1445, #1446, #1451

    opened by tschoonj 62
  • rpath doesn't get set with find_library('foo', dirs:'/path/to/lib')

    rpath doesn't get set with find_library('foo', dirs:'/path/to/lib')

    Hi Jussi,

    If you build a shared object with meson, the rpath get sets correctly (or so the docs say), but when I use find_library() and give it a search path, the rpath doesn't get set. This is causing me lot of pain.

    I'm currently doing stuff like this:

    thirdparty_root = '/usr/local/thirdparty-1.6.0'
    thirdparty_lib = [thirdparty_root + '/lib/linux-x64-all',
        thirdparty_root + '/lib/linux-x64-gcc4.8'
    ]
    thirdparty_rpath = thirdparty_lib[0] + ':' + thirdparty_lib[1]
    
    thirdparty_dep = declare_dependency(
        include_directories: thirdparty_inc,
        dependencies: [
            find_library('lib1', dirs: thirdparty_lib),
            find_library('lib2', dirs: thirdparty_lib),
            find_library('lib3', dirs: thirdparty_lib)
        ]
    )
    

    Then doing this:

    executable('foo', 'foo.cpp',
       ...,
        link_args: '-Wl,-rpath,@0@:@1@'.format(thirdparty_rpath, boost_rpath),
    )
    

    Am I doing it wrong?

    bug enhancement compilers dependencies 
    opened by rhd 56
  • Please provide a user-configurable, global way to specify RPATH/RUNPATH for the whole project.

    Please provide a user-configurable, global way to specify RPATH/RUNPATH for the whole project.

    Currently meson does not provide a way to specify a custom rpath, it removes rpath in install step even if it was specified via LDFLAGS. https://github.com/NixOS/nixpkgs/pull/28444#issuecomment-324033323

    Please note: I'm aware about {build,install}_rpath, these are project or target options. I'm talking about something like cmake's CMAKE_INSTALL_RPATH which can be easily passed to cmake while configuring. Even autohell behaves fine with such use case. What I'm asking for is an option like --meson-install-rpath (like --prefix) which would allow users (project consumers, not developers) to build and install packages into a custom prefix without messing with meson.build .

    This is needed when you want to install something into an arbitrary prefix to avoid overwriting system stuff, eg. you want to build something with new shiny features straight from git, but you don't want to break your OS.

    Please consider adding such a feature.

    PS: LD_RUN_PATH et al is not an option, the rest of the system should not know anything "prefixed" installs.

    enhancement compilers 
    opened by asavah 53
  • New builtin-option to support partial linking for shared libraries

    New builtin-option to support partial linking for shared libraries

    Added a new builtin-option called 'sharedlib-linkmodel' for being able to generate a partial linked object using a shared_library() target.

    • when this option value is set to 'standard', the existing shared library linking method is used as is and is the default value.
    • when this option value is set to 'partial', required compiler options for generating partial linked object will be selected and few of the 'standard' linking options are skipped. Currently the support is added for armcc, armclang and gnu compilers, a warning will be generated if this option is set to 'partial' while using any other compilers.
    opened by sompen 47
  • Add a summary() function for configuration summarization

    Add a summary() function for configuration summarization

    This has been requested multiple times in the mesa/xorg community, and apparently in the GStreamer community as well.

    This allows a configuration summary to be printed at the end of the configuring phase.

    For example:

    sec1 = {'driver' : 'foobar', 'OS' : 'Linux', 'API' : 1.7}
    ...
    sec2 = {'driver' : 'dive comp', 'OS' : 'Minix', 'API' : 1.1.2}
    ...
    sec3 = {'with' : {'mesa' : true, 'gbm' : false}}
    
    summary(
      {'Backend' : 'OpenGL'},
      'Server' : sec1,
      'Client' : sec2,
      'Misc' : sec3,
    )
    

    Which would print something like:

    Configuration Summary:
      Backend = OpenGL
      Server:
        driver = foobar
        OS = Linux
        API = 1.7
      Client:
        driver = dive comp
        OS = Minix
        API = 1.1.2
      Misc:
        with = {'mesa : true, 'gbm' : false}
    

    Fixes #757

    opened by dcbaker 47
  • Cargo integration in Meson via an

    Cargo integration in Meson via an "unstable-cargo" module (try 2)

    This was made primarily so we can build librsvg with Meson, which now works: https://git.gnome.org/browse/librsvg/log/?h=wip/meson, and it actually required fewer hacks than I expected it to.

    The integration can and should definitely be better, but I think the best way to get there is to have something that works right now and slowly improve Cargo till we have everything we need. Cargo is not going to magically grow API for giving greater control to build systems; we have to work towards it.

    I have been talking to @alexcrichton about the things that Meson would need to integrate better with Cargo, and he has been very receptive and encouraging of our efforts, and in the need for adding features to Cargo that allow Meson to control what it does a bit better.

    Here's what you can do right now:

    'Extract' build outputs from Cargo.toml files in your source tree with the unstable-cargo module and mostly use them like you would any other target. For example:

    cargo = import('unstable-cargo')
    # Build the staticlib
    librsvg_internals = cargo.static_library('rsvg_internals', toml : 'Cargo.toml')
    
    librsvg = library('rsvg-' + rsvg_api_major, librsvg_sources,
                      dependencies : [librsvg_deps, librsvg_internals])
    

    You can also specify the list of sources if you wish:

    cargo.executable('mesonbin',
                     toml : 'Cargo.toml',
                     # This is optional, since ninja keeps track of dependencies on source files.
                     sources : ['src/main.rs'],
                     # Yes, installation works
                     install : true)
    

    The sources list is optional because cargo will output a nice depfile for us and ninja can then keep track of when to rebuild the target.

    Meson TODO:

    • Cross-compilation
    • Cargo tests and benchmarks
    • cdylibs or rust-specific library types
    • ninja dist does not support vendoring crate sources yet (needed for librsvg)

    Cargo TODO:

    • https://github.com/rust-lang/cargo/pull/4711
    • CARGO_TARGET_DIR should be an argument --target-dir
    • Options to set the output library/executable name (prefix/suffix); perhaps also in Cargo.toml
    • In general, the ability to more accurately control build outputs from via cargo arguments
      • This is where our work comes in; something half-working is the best way to figure out what is needed to make it work well ;)
    • Dry-run downloading of sources by cargo vendor so we can ship a list of files instead of the sources themselves (cc @alexlarsson)

    Cargo long-term TODO:

    • Output rustc invocations needed to build a crate so we can run everything ourselves
    • Overall, Meson should be able to output build artifacts exactly where it wants, and with the rustc flags that we want.
    opened by nirbheek 47
  • 1st class Cython language support

    1st class Cython language support

    Okay, I stopped thinking about it and started writing code. This is not complete, there's a fair number of things not done (listed below). Currently, this is just enough to build one trivial test case, but I think it touches all the places that need to be changed, even if there is more work to do. I'm not sure how much more time I'll be able to spend on this, but here's a starting point if someone else wants to take it up.

    TODO:

    • [x] handle a single static source
    • [x] handle a single generated source
    • [ ] handle a mixture of static and generated sources
    • [x] work out the best way to handle python 2 support (if it's needed at all)
    • [ ] work out the best way to handle Cython -> C++
    • [ ] deal with the fact that filesystem layout matters (also a problem for Rust and Zig)
    opened by dcbaker 46
  • Wrong cpu  detection for 'x86_64' windows

    Wrong cpu detection for 'x86_64' windows

    In ‘x64 Native Tools Command Prompt for VS 2017’, the cpu detected by meson is 'x86' ?

    **********************************************************************
    ** Visual Studio 2017 Developer Command Prompt v15.9.16
    ** Copyright (c) 2017 Microsoft Corporation
    **********************************************************************
    [vcvarsall.bat] Environment initialized for: 'x64'
    
    D:\opt\glib-2.62.2\_build>meson .. --buildtype=release --prefix="D:\opt\glib\"
    The Meson build system
    Version: 0.52.0
    Source dir: D:\opt\glib-2.62.2
    Build dir: D:\opt\glib-2.62.2\_build
    Build type: native build
    Project name: glib
    Project version: 2.62.2
    C compiler for the host machine: cl (msvc 19.16.27034)
    C linker for the host machine: link 19.16.27034
    C++ compiler for the host machine: cl (msvc 19.16.27034)
    C++ linker for the host machine: link 19.16.27034
    Host machine cpu family: x86
    Host machine cpu: x86
    

    And I tried in vs2013 , 2015, got the same result.

    OS:windows regression 
    opened by sz-CHEN 46
  • Failed when specifying a directory as `input` for `custom_target` or `generator`

    Failed when specifying a directory as `input` for `custom_target` or `generator`

    Describe the bug When specifying the input argument or custom_target or generator with a directory path, it will fail with

    ERROR: File <directory path> does not exist.
    

    A build target may depends on a directory both theoretically and practically, and GNU Make does allow directories to serve as dependencies or build targets. In my use case, I would like to generate a file archive for each input directories. There should be a way to do that with Meson so as to cover these use cases.

    This was originally posted in discussion in https://github.com/mesonbuild/meson/discussions/11230 . After searching through the documentation without finding a workaround, I guess this should be considered an issue.

    To Reproduce

    1. Construct the following directories and files:
    srcdir
    ├── gen_zip.sh
    ├── meson.build
    └── sample_hello.source
        ├── empty
        └── hello.txt
    
    1 directory, 4 files
    

    gen_zip.sh

    #!/bin/sh
    
    INPUT_DIR="$1"
    OUTPUT="$(realpath "$2")"
    
    cd "$INPUT_DIR" || exit 1
    find . -mindepth 1 -maxdepth 1 -exec zip -r -y "$OUTPUT" "{}" \+
    

    hello.txt

    Hello world!
    

    meson.build

    project('my-project', 'c',
    version: '0.1.0',
    license: 'MIT',
    default_options: [
      'buildtype=debugoptimized',
      'c_std=c11',
      'warning_level=3'
    ])
    
    exe_gen_zip = find_program('./gen_zip.sh')
    
    sample_hello = custom_target('sample_hello',
    input: 'sample_hello.source',
    output: 'sample_hello.zip',
    command: [
      exe_gen_zip,
      '@INPUT@',
      '@OUTPUT@'
    ])
    
    1. Run

      touch "srcdir/sample_hello.source/empty"
      chmod +x "srcdir/gen_zip.sh"
      
    2. Run

      cd srcdir
      meson setup build.tmp
      
    3. See error

      meson.build:12:0: ERROR: File sample_hello.source does not exist.
      

    Expected behavior

    Users should be able to use custom_target and generator.process with directories as input, and the above build steps should run without the file-not-found error.

    system parameters

    • Is this a cross build or just a plain native build (for the same computer)? This is a native build.
    • what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) NixOS
      • system: "x86_64-linux"
      • host os: Linux 5.15.80, NixOS, 22.11 (Raccoon), 22.11.20221130.596a8e8
      • multi-user?: yes
      • sandbox: yes
      • version: nix-env (Nix) 2.11.0
      • nixpkgs: /nix/store/qwgw2b19ga8dr7c6wfpd6p87bdjyrnha-source
    • what Python version are you using: 3.10.8
    • what meson --version: 0.63.1
    • what ninja --version if it's a Ninja build: 1.11.1
    opened by ShamrockLee 1
  • add implementation of get_dependency_gen_args() for cuda compiler

    add implementation of get_dependency_gen_args() for cuda compiler

    Without get_dependency_gen_args() depfiles are not generated for cuda sources and can result in partial target rebuilds when source dependency changes occur in the project.

    The nvcc preprocessor now supports -MD, -MDD, -MF, but still lacks implementation support for -MQ, instead providing only -MT. Supporting -MD and -MF overcomes previous limitations where nvcc required depfile generation in two commands and this was not possible with ninja. Using -MT is not great, but may be better than nothing for the moment. https://github.com/mesonbuild/meson/issues/1003#issuecomment-259103463 https://github.com/mesonbuild/meson/discussions/11227#discussioncomment-4553800

    opened by mitchburnett 2
  • Regression setting PKG_CONFIG_LIBDIR  with msys2 pkg-config after 0.62.1

    Regression setting PKG_CONFIG_LIBDIR with msys2 pkg-config after 0.62.1

    Describe the bug Commit 18bec0d3e31884dc493a03741b2ec9fef17047ee introduces a regression in my build setup with the way it sets PKG_CONFIG_LIBDIR. In this particular configuration I use msys2 pkg-config which expects Unix-style path separator (':') in env vars. It seems that aformentioned commit changes the path separator to windows-style (';') which is no longer recongized by pkg-config and dependency discovery fails. I'm not aware if there's any other pkg-config variant usable on Windows which uses ';' as a separator, msys seems lika a natural choice.

    meson-log.txt before the commit:

    env[PKG_CONFIG_LIBDIR]: c:\data2\moonlight-deps\windows-clang15\icu4c-71_1\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\cmph-2.0\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\openssl-1.1.1s\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\xxHash-0.8.1\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\zlib-1.2.13\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\zstd-1.5.2\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\flac-1.3.2\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\libogg-1.3.5\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\opus-1.3.1\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\opusfile-0.12\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\libsndfile-1.1.0\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\soxr-0.1.3\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\libvorbis-1.3.7\x64\lib\pkgconfig:c:\data2\moonlight-deps\windows-clang15\yaml-cpp-0.7.0\x64\share\pkgconfig
    

    after the commit:

    env[PKG_CONFIG_LIBDIR]: c:\data2\moonlight-deps\windows-clang15\icu4c-71_1\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\cmph-2.0\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\openssl-1.1.1s\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\xxHash-0.8.1\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\zlib-1.2.13\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\zstd-1.5.2\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\flac-1.3.2\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\libogg-1.3.5\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\opus-1.3.1\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\opusfile-0.12\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\libsndfile-1.1.0\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\soxr-0.1.3\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\libvorbis-1.3.7\x64\lib\pkgconfig;c:\data2\moonlight-deps\windows-clang15\yaml-cpp-0.7.0\x64\share\pkgconfig
    

    This causes the discovery of libcrypto to fail:

    moonlight-tools| Run-time dependency libcrypto found: NO (tried pkgconfig, system and cmake)
    
    subprojects\moonlight-tools\src\meson.build:2:0: ERROR: Dependency "libcrypto" not found, tried pkgconfig, system and cmake
    

    To Reproduce Please include your meson.build files, preferably as a minimal toy example showing the issue. You may need to create simple source code files (don't include private/proprietary code).

    setup command:

     meson setup build -Dbuildtype=release -Dwrap_mode=forcefallback -Db_lto=false -Ddebug=True -Doptimization=3 -Db_ndebug=false -Denable_cuda=true --native-file tools/meson/windows.conf --native-file tools/meson/windows/x64.conf
    

    windows.conf:

    [constants]
    deps_dir = 'c:\data2\moonlight-deps\windows-clang15'
    boost_stem = 'boost_1_80_0'
    cmph_stem = 'cmph-2.0'
    icu4c_stem = 'icu4c-71_1'
    openssl_stem = 'openssl-1.1.1s'
    xxhash_stem = 'xxHash-0.8.1'
    zlib_stem = 'zlib-1.2.13'
    yaml_cpp_stem = 'yaml-cpp-0.7.0'
    flac_stem = 'flac-1.3.2'
    ogg_stem = 'libogg-1.3.5'
    opus_stem = 'opus-1.3.1'
    opusfile_stem = 'opusfile-0.12'
    sndfile_stem = 'libsndfile-1.1.0'
    soxr_stem = 'soxr-0.1.3'
    vorbis_stem = 'libvorbis-1.3.7'
    zstd_stem = 'zstd-1.5.2'
    thinlto_cache_dir = 'c:\ThinLTO'
    
    [properties]
    clang_target = 'msvc'
    platform = platform
    deps_dir = deps_dir
    boost_root = deps_dir / boost_stem
    pkg_config_libdir = [
        deps_dir / icu4c_stem / platform / 'lib\pkgconfig',
        deps_dir / cmph_stem / platform / 'lib\pkgconfig',
        deps_dir / openssl_stem / platform / 'lib\pkgconfig',
        deps_dir / xxhash_stem / platform / 'lib\pkgconfig',
        deps_dir / zlib_stem / platform / 'lib\pkgconfig',
        deps_dir / zstd_stem / platform / 'lib\pkgconfig',
        deps_dir / flac_stem / platform / 'lib\pkgconfig',
        deps_dir / ogg_stem / platform / 'lib\pkgconfig',
        deps_dir / opus_stem / platform / 'lib\pkgconfig',
        deps_dir / opusfile_stem / platform / 'lib\pkgconfig',
        deps_dir / sndfile_stem / platform / 'lib\pkgconfig',
        deps_dir / soxr_stem / platform / 'lib\pkgconfig',
        deps_dir / vorbis_stem / platform / 'lib\pkgconfig',
        deps_dir / yaml_cpp_stem / platform / 'share\pkgconfig']
    cuda_lib_dir = cuda_lib_dir
    thinlto_cache_dir = thinlto_cache_dir
    
    [built-in options]
    c_link_args = ['-Wl,/lldltocache:' + thinlto_cache_dir]
    cpp_link_args = c_link_args
    cpp_args = [
        # XXX workaround: boost/type_traits/has_trivial_copy.hpp:34:4: error: builtin __has_trivial_copy is deprecated
        '-Wno-deprecated-builtins',
        # XXX workaround: https://github.com/llvm/llvm-project/issues/56300
        '-D_DISABLE_STRING_ANNOTATION',
        '-D_DISABLE_VECTOR_ANNOTATION']
    
    [project options]
    CUDA_dir = 'C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.8'
    
    [binaries]
    pkgconfig = 'c:\msys64\usr\bin\pkg-config'
    c = ['c:\msys64\mingw64\bin\ccache', 'clang', '--target=' + clang_target]
    cpp = ['c:\msys64\mingw64\bin\ccache', 'clang++', '--target=' + clang_target]
    c_ld = 'lld'
    cpp_ld = 'lld'
    strip = 'llvm-strip'
    ar = 'llvm-ar'
    nm = 'llvm-nm'
    ranlib = 'llvm-ranlib'
    

    x64.conf:

    [constants]
    platform = 'x64'
    platform_bits = '64'
    cuda_lib_dir = 'lib\x64'
    clang_target = 'x86_64-pc-windows-msvc'
    

    (minimized) meson.build:

    project('foo', 'cpp',
      meson_version: '>= 0.56.0',
      default_options: [
        'cpp_std=c++20',
        'werror=true',
        'warning_level=2',
        'b_lto=true',
        'b_lto_mode=thin',
    ])
    
    deps = [
      dependency('libcrypto', static: true, required: true, include_type: 'system'),
      dependency('libxxhash', static: true, required: true, include_type: 'system'),
    ]
    ...
    

    Expected behavior I expect the build setup to succeed just like it did before commit 18bec0d3e31884dc493a03741b2ec9fef17047ee

    system parameters

    • native build
    • Windows 10
    • Python 3.9.1
    • meson --version 0.62.99 (doesn't happen with 0.62.1, happens after 18bec0d3e31884dc493a03741b2ec9fef17047ee)
    • ninja --version 1.10.2
    opened by andrzejc 2
  • clang-cl supports /std:c++20 now.

    clang-cl supports /std:c++20 now.

    clang-cl now supports /std:c++20. I'm not sure exactly when it was added, but given ClangClCPPCompiler does no version checking (at least from a cursory comparison with VisualStudioCPPCompiler), I guess that's not an issue. Anyway, it's certainly there in current (i.e. clang-cl 15.0.1 from VS 17.4.3).

    Obviously preferable to use over c++latest as that enables a lot of C++23 stuff...

    Here's a quick fix if you want it. Wasn't sure if it warrants a release snippet since it's not really a new feature, but happy to add it.

    Thanks

    opened by lukester1975 4
  • Improve error handling for gcc directory search

    Improve error handling for gcc directory search

    This fixes a bug where meson fails to build on windows due to msys2 containing incorrect build paths. Most of the time Windows simply says that the directory doesn't exist, but in special cases (such as with BitLocker), an exception is thrown that blocks the build.

    This catches the exception and converts it to a warning.

    How these warnings look like in practice:

    C:\envs\venv\Lib\site-packages\mesonbuild\compilers\mixins\gnu.py:497: UserWarning: Error processing directory [WinError -2144272384] This drive is locked by BitLocker Drive Encryption. You must unlock this drive from Control Panel: 'D:\a\_temp\msys64\ucrt64\x86_64-w64-mingw32\lib\x86_64-w64-mingw32\10.3.0'

    opened by Lalaland 8
Releases(1.0.0)
Owner
The Meson Build System
Meson is an open source build system meant to be both extremely fast, and, even more importantly, as user friendly as possible.
The Meson Build System
The Pants Build System

Pants Build System Pants is a scalable build system for monorepos: codebases containing multiple projects, often using multiple programming languages

Pants Build 2.5k Jan 7, 2023
Clang-based cross platform build system written in Python

Clang-build Find the full documentation at https://clang-build.readthedocs.io First steps Customisations Multiple targets Multiple projects Defaults M

Trick 17 9 Jun 29, 2022
Software build automation tool for Python.

PyBuilder — an easy-to-use build automation tool for Python PyBuilder is a software build tool written in 100% pure Python, mainly targeting Python ap

PyBuilder 1.5k Jan 4, 2023
A pynt of Python build.

A pynt of Python build. Raghunandan Rao Features Easy to learn. Build tasks are just python funtions. Manages dependencies between tasks. Automaticall

Raghunandan Rao 154 Jan 4, 2023
🔨🐍Make-like build automation tool for Python projects with extensive DSL features.

Pyke (WIP, Beta Release) Make-like build automation tool for Python projects with extensive DSL features. Features: Users can specify tasks, subtasks,

Ire 17 Jul 5, 2022
A Star Trek Online build tool in Python

SETS - STO Equipment and Trait Selector A Star Trek Online build tool in Python Description Pre-alpha version of build tool for STO Getting Started De

Star Trek Online Community Developers 7 Nov 12, 2022
Minimisation of a negative log likelihood fit to extract the lifetime of the D^0 meson (MNLL2ELDM)

Minimisation of a negative log likelihood fit to extract the lifetime of the D^0 meson (MNLL2ELDM) Introduction The average lifetime of the $D^{0}$ me

Son Gyo Jung 1 Dec 17, 2021
Ubuntu env build; Nginx build; DB build;

Deploy 介绍 Deploy related scripts bitnami Dependencies Ubuntu openssl envsubst docker v18.06.3 docker-compose init base env upload https://gitlab-runn

Colin(liuji) 10 Dec 1, 2021
:package: :fire: Python project management. Manage packages: convert between formats, lock, install, resolve, isolate, test, build graph, show outdated, audit. Manage venvs, build package, bump version.

THE PROJECT IS ARCHIVED Forks: https://github.com/orsinium/forks DepHell -- project management for Python. Why it is better than all other tools: Form

DepHell 1.7k Dec 30, 2022
An easy way to build PyTorch datasets. Modularly build datasets and automatically cache processed results

EasyDatas An easy way to build PyTorch datasets. Modularly build datasets and automatically cache processed results Installation pip install git+https

Ximing Yang 4 Dec 14, 2021
Official project repository for the Setuptools build system

See the Installation Instructions in the Python Packaging User's Guide for instructions on installing, upgrading, and uninstalling Setuptools. Questio

Python Packaging Authority 1.9k Jan 8, 2023
The Pants Build System

Pants Build System Pants is a scalable build system for monorepos: codebases containing multiple projects, often using multiple programming languages

Pants Build 2.5k Jan 7, 2023
open-information-extraction-system, build open-knowledge-graph(SPO, subject-predicate-object) by pyltp(version==3.4.0)

中文开放信息抽取系统, open-information-extraction-system, build open-knowledge-graph(SPO, subject-predicate-object) by pyltp(version==3.4.0)

null 7 Nov 2, 2022
Ninja is a small build system with a focus on speed.

Ninja Python Distributions Ninja is a small build system with a focus on speed. The latest Ninja python wheels provide ninja 1.10.2.g51db2.kitware.job

null 33 Dec 19, 2022
Clang-based cross platform build system written in Python

Clang-build Find the full documentation at https://clang-build.readthedocs.io First steps Customisations Multiple targets Multiple projects Defaults M

Trick 17 9 Jun 29, 2022
Build AGNOS, the operating system for your comma three

agnos-builder This is the tool to build AGNOS, our Ubuntu based OS. AGNOS runs on the comma three devkit. NOTE: the edk2_tici and agnos-firmare submod

comma.ai 21 Dec 24, 2022
A dynamic multi-STL, multi-process OpenSCAD build system with autoplating support

scad-build This is a multi-STL OpenSCAD build system based around GNU make. It supports dynamic build targets, intelligent previews with user-defined

Jordan Mulcahey 1 Dec 21, 2021
Build a medical knowledge graph based on Unified Language Medical System (UMLS)

UMLS-Graph Build a medical knowledge graph based on Unified Language Medical System (UMLS) Requisite Install MySQL Server 5.6 and import UMLS data int

Donghua Chen 6 Dec 25, 2022
OptiPLANT is a cloud-based based system that empowers professional and non-professional data scientists to build high-quality predictive models

OptiPLANT OptiPLANT is a cloud-based based system that empowers professional and non-professional data scientists to build high-quality predictive mod

Intellia ICT 1 Jan 26, 2022
AoT is a system for automatically generating off-target test harness by using build information.

AoT: Auto off-Target Automatically generating off-target test harness by using build information. Brought to you by the Mobile Security Team at Samsun

Samsung 10 Oct 19, 2022