rust-lang / cmake-rs Goto Github PK

Partially related to #28.

Would you be receptive to a PR adding Windows CI? I'm in the process of submitting a PR to FlatBuffers and I'm seeing what looks like invalid generated cmake commands on their AppVeyor CI jobs:

--- stdout
running: "cmake" "C:\\projects\\flatbuffers\\rust\\flatc\\..\\.." "-Thost=x64" "-DCMAKE_GENERATOR_PLATFORM=x64" "-G" "Visual Studio 10 2010" "-DCMAKE_BUILD_TYPE=Release" "-DCMAKE_INSTALL_BINDIR=bin" "-DFLATBUFFERS_BUILD_TESTS=OFF" "-DFLATBUFFERS_BUILD_FLATLIB=OFF" "-DFLATBUFFERS_BUILD_FLATHASH=OFF" "-DCMAKE_INSTALL_PREFIX=C:\\projects\\flatbuffers\\tests\\rust_usage_test\\target\\debug\\build\\flatc-a64531bc5efc6cfc\\out" "-DCMAKE_C_FLAGS= /nologo /MD" "-DCMAKE_CXX_FLAGS= /nologo /MD"
-- Found Windows SDK v7.1: C:\Program Files\Microsoft SDKs\Windows\v7.1\
-- Configuring incomplete, errors occurred!
See also "C:/projects/flatbuffers/tests/rust_usage_test/target/debug/build/flatc-a64531bc5efc6cfc/out/build/CMakeFiles/CMakeOutput.log".
--- stderr
CMake Error at CMakeLists.txt:6 (project):
  Generator
    Visual Studio 10 2010
  given toolset specification
    host=x64
  that contains invalid field 'host=x64'.

Seems to me like it should generate cmake -G "Visual Studio 10 2010 Win64" without -Thost=x64 as pointed out in the prior issue.

While looking through the code I observed that the visual_studio_generator function sets an incorrect generator for the VS "15.0" version(I was using CMake 3.8-rc and observed that it has a different generator).

Here is the list of generators that 3.8.0 reports on this Windows machine:

The following generators are available on this platform:
  Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                 Optional [arch] can be "Win64" or "ARM".
  Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                 Optional [arch] can be "Win64" or "IA64".
  Visual Studio 8 2005 [arch]  = Generates Visual Studio 2005 project files.
                                 Optional [arch] can be "Win64".
  Visual Studio 7 .NET 2003    = Deprecated.  Generates Visual Studio .NET
                                 2003 project files.
  Borland Makefiles            = Generates Borland makefiles.
  NMake Makefiles              = Generates NMake makefiles.
  NMake Makefiles JOM          = Generates JOM makefiles.
  Green Hills MULTI            = Generates Green Hills MULTI files
                                 (experimental, work-in-progress).
  MSYS Makefiles               = Generates MSYS makefiles.
  MinGW Makefiles              = Generates a make file for use with
                                 mingw32-make.
  Unix Makefiles               = Generates standard UNIX makefiles.
  Ninja                        = Generates build.ninja files.
  Watcom WMake                 = Generates Watcom WMake makefiles.
  CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles = Generates CodeBlocks project files.
  CodeBlocks - NMake Makefiles JOM
                               = Generates CodeBlocks project files.
  CodeBlocks - Ninja           = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - MinGW Makefiles   = Generates CodeLite project files.
  CodeLite - NMake Makefiles   = Generates CodeLite project files.
  CodeLite - Ninja             = Generates CodeLite project files.
  CodeLite - Unix Makefiles    = Generates CodeLite project files.
  Sublime Text 2 - MinGW Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - NMake Makefiles
                               = Generates Sublime Text 2 project files.
  Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
                               = Generates Sublime Text 2 project files.
  Kate - MinGW Makefiles       = Generates Kate project files.
  Kate - NMake Makefiles       = Generates Kate project files.
  Kate - Ninja                 = Generates Kate project files.
  Kate - Unix Makefiles        = Generates Kate project files.
  Eclipse CDT4 - NMake Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - MinGW Makefiles
                               = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.

Howdy howdy!

https://github.com/alexcrichton/cmake-rs/blob/master/src/lib.rs#L379

This is fine on most machines, but I was plopped into trouble once I tried to do some work on a machine with a non-standard installation location. I forked and am testing but want to get a gut check first.

I was going to start using the version reported by cl.exe instead of it's location first. Are there some other ideas I should try? Environment variables perhaps?

Right now cmake-rs seems to default to VisualStudio as the generator if the rustc target is msvc. However in my particular use case I would like to use Ninja. Ordinarily, the user of cmake-rs (in this case the build.rs script in servo-freetype-sys) would just set .generator("Ninja") and that would be fine. However that will change it for all consumers of servo-freetype-sys instead of just for my environment.

What I would like to do is add some sort of env var that I can set that will set the generator to be Ninja. But I'm unsure if the env var should be read from cmake-rs or from servo-freetype-sys. @alexcrichton Thoughts?

On the one hand I'm leaning towards doing it in servo-freetype-sys because it's a smaller change there. But on the other hand if I have a crate that depends on multiple sub-crates that all build stuff with cmake, it kind of makes sense to just put it in cmake-rs since the environment that's doing the build will have the same build tools available (in my case, Ninja) for all the sub-crates, and having to modify each sub-crate seems like a waste.

https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler-1

You can now use -C target-feature=+crt-static on linux-gnu targets. Note: If you're using cargo you must explicitly pass the --target flag.

But when I run

RUSTFLAGS="-C target-feature=+crt-static" cargo build --release --target x86_64-unknown-linux-gnu

my dep that uses cmake fails with:

error: failed to run custom build command for `ffts v0.1.0 (ssh://[email protected]/Boscop/ffts-rs#ef6850c8)`

Caused by:
  process didn't exit successfully: `/home/me/projects/myproject/target/release/build/ffts-a7bc83ba5c7e316e/build-script-build` (exit code: 101)
  --- stdout
  running: "cmake" "/home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts" "-DCMAKE_INSTALL_PREFIX=/home/me/projects/myproject/target/x86_64-unknown-linux-gnu/release/build/ffts-63735e55463d2390/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -static" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -static" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64 -static" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release"
  -- The C compiler identification is GNU 10.2.0
  -- The ASM compiler identification is GNU
  -- Found assembler: /usr/bin/cc
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/bin/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Looking for inttypes.h
  -- Looking for inttypes.h - found
  -- Looking for malloc.h
  -- Looking for malloc.h - found
  -- Looking for mm_malloc.h
  -- Looking for mm_malloc.h - found
  -- Looking for stdint.h
  -- Looking for stdint.h - found
  -- Looking for stdlib.h
  -- Looking for stdlib.h - found
  -- Looking for string.h
  -- Looking for string.h - found
  -- Looking for sys/mman.h
  -- Looking for sys/mman.h - found
  -- Looking for unistd.h
  -- Looking for unistd.h - found
  -- Looking for memalign
  -- Looking for memalign - found
  -- Looking for posix_memalign
  -- Looking for posix_memalign - found
  -- Looking for valloc
  -- Looking for valloc - found
  -- Looking for _mm_malloc
  -- Looking for _mm_malloc - not found
  -- Looking for memalign
  -- Looking for memalign - found
  -- Looking for posix_memalign
  -- Looking for posix_memalign - found
  -- Looking for valloc
  -- Looking for valloc - found
  -- Looking for _mm_malloc
  -- Looking for _mm_malloc - not found
  -- Looking for xmmintrin.h
  -- Looking for xmmintrin.h - found
  -- Looking for emmintrin.h
  -- Looking for emmintrin.h - found
  -- Looking for pmmintrin.h
  -- Looking for pmmintrin.h - found
  -- Performing Test HAVE_GCC_VISIBILITY
  -- Performing Test HAVE_GCC_VISIBILITY - Success
  -- Looking for pow in m
  -- Looking for pow in m - found
  -- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) 
  -- Could NOT find OpenMP (missing: OpenMP_C_FOUND) 
  -- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3") 
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /home/me/projects/myproject/target/x86_64-unknown-linux-gnu/release/build/ffts-63735e55463d2390/out/build
  running: "cmake" "--build" "." "--target" "install" "--config" "Release" "--"
  Scanning dependencies of target ffts_cpu_test
  [  5%] Building C object CMakeFiles/ffts_cpu_test.dir/src/ffts_cpu.c.o
  [ 11%] Building C object CMakeFiles/ffts_cpu_test.dir/tests/cpu_test.c.o
  [ 16%] Linking C executable ffts_cpu_test
  [ 16%] Built target ffts_cpu_test
  Scanning dependencies of target ffts_static
  [ 22%] Building C object CMakeFiles/ffts_static.dir/src/ffts.c.o
  [ 27%] Building C object CMakeFiles/ffts_static.dir/src/ffts_chirp_z.c.o
  [ 33%] Building C object CMakeFiles/ffts_static.dir/src/ffts_cpu.c.o
  [ 38%] Building C object CMakeFiles/ffts_static.dir/src/ffts_nd.c.o
  [ 44%] Building C object CMakeFiles/ffts_static.dir/src/ffts_real.c.o
  [ 50%] Building C object CMakeFiles/ffts_static.dir/src/ffts_real_nd.c.o
  [ 55%] Building C object CMakeFiles/ffts_static.dir/src/ffts_transpose.c.o
  [ 61%] Building C object CMakeFiles/ffts_static.dir/src/ffts_trig.c.o
  [ 66%] Building C object CMakeFiles/ffts_static.dir/src/ffts_static.c.o
  [ 72%] Building C object CMakeFiles/ffts_static.dir/src/codegen.c.o
  [ 77%] Linking C static library libffts.a
  [ 77%] Built target ffts_static
  Scanning dependencies of target ffts_test
  [ 83%] Building C object CMakeFiles/ffts_test.dir/tests/test.c.o
  [ 88%] Linking C executable ffts_test
  [ 88%] Built target ffts_test
  Scanning dependencies of target ffts_trig_test
  [ 94%] Building C object CMakeFiles/ffts_trig_test.dir/tests/trig_test.c.o
  [100%] Linking C executable ffts_trig_test

  --- stderr
  CMake Warning:
    Manually-specified variables were not used by the project:

      CMAKE_CXX_COMPILER
      CMAKE_CXX_FLAGS


  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts.c: In function ‘ffts_init_1d_64f’:
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts.c:784:25: warning: unused parameter ‘N’ [-Wunused-parameter]
    784 | ffts_init_1d_64f(size_t N, int sign)
        |                  ~~~~~~~^
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts.c:784:32: warning: unused parameter ‘sign’ [-Wunused-parameter]
    784 | ffts_init_1d_64f(size_t N, int sign)
        |                            ~~~~^~~~
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts_static.c:240:36: warning: ‘ffts_constants_inv_64f’ defined but not used [-Wunused-const-variable=]
    240 | static const FFTS_ALIGN(16) double ffts_constants_inv_64f[16] = {
        |                                    ^~~~~~~~~~~~~~~~~~~~~~
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts_static.c:196:36: warning: ‘ffts_constants_64f’ defined but not used [-Wunused-const-variable=]
    196 | static const FFTS_ALIGN(16) double ffts_constants_64f[16] = {
        |                                    ^~~~~~~~~~~~~~~~~~
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts_static.c:142:36: warning: ‘ffts_constants_small_inv_64f’ defined but not used [-Wunused-const-variable=]
    142 | static const FFTS_ALIGN(16) double ffts_constants_small_inv_64f[24] = {
        |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/ffts_static.c:78:36: warning: ‘ffts_constants_small_64f’ defined but not used [-Wunused-const-variable=]
     78 | static const FFTS_ALIGN(16) double ffts_constants_small_64f[24] = {
        |                                    ^~~~~~~~~~~~~~~~~~~~~~~~
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/codegen.c: In function ‘ffts_generate_func_code’:
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/codegen.c:282:19: warning: comparison of integer expressions of different signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int32_t’ {aka ‘int’} [-Wsign-compare]
    282 |         if (ws_is != pLUT) {
        |                   ^~
  /home/me/.cargo/git/checkouts/ffts-rs-90217fe977f2ad3e/ef6850c/ffts/src/codegen.c:121:15: warning: unused variable ‘len’ [-Wunused-variable]
    121 |     ptrdiff_t len;
        |               ^~~
  /usr/bin/ld: cannot find -lmpfr
  collect2: error: ld returned 1 exit status
  make[2]: *** [CMakeFiles/ffts_trig_test.dir/build.make:105: ffts_trig_test] Error 1
  make[1]: *** [CMakeFiles/Makefile2:155: CMakeFiles/ffts_trig_test.dir/all] Error 2
  make: *** [Makefile:149: all] Error 2
  thread 'main' panicked at '
  command did not execute successfully, got: exit code: 2

  build script failed, must exit now', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.44/src/lib.rs:885:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

Any idea how I can make it work? :)

(Note that a normal cargo build --release works.)

currently there is no easy way to pass linker flags to cmake

Usually source files should not be executable. The src/lib.rs file has the executable bit set, and that property also gets distributed through the downloads from crates.io. I stumbled upon this problem when attempting to update the cmake-rs Debian package, because the lintian tool shows a warning for that.
I assume it's impossible to modify the already-distributed version on crates.io, but it would help for future versions.

I have seen an error similar to #95 while building grpc-sys. It looks like with cmake-rs 0.1.43 & 0.1.44, CMAKE_ASM_COMPILER will be explicitly specified to /usr/bin/cc, and for some reason this made CMake to not able to identify the assembler type. This subsequently caused incorrect compiler flag being generated.

From CMake's record, with cmake-rs == 0.1.44. The generated configration is:

running: "cmake" "/Users/fanzeyi/.cargo/registry/src/github.com-1ecc6299db9ec823/grpcio-sys-0.5.3/grpc" "-DgRPC_INSTALL=false" "-DgRPC_BUILD_CSHARP_EXT=false" "-DgRPC_BUILD_CODEGEN=false" "-DgRPC_BENCHMARK_PROVIDER=none" "-DgRPC_ZLIB_PROVIDER=package" "-DCMAKE_INSTALL_PREFIX=/Users/fanzeyi/GitHub/project/target/debug/build/grpcio-sys-2c04b4ba668021f3/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -stdlib=libc++ -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"
-- The ASM compiler identification is unknown
-- Found assembler: /usr/bin/cc
-- Warning: Did not find file Compiler/-ASM
...

With cmake-rs == 0.1.42, CMake has:

running: "cmake" "/Users/fanzeyi/.cargo/registry/src/github.com-1ecc6299db9ec823/grpcio-sys-0.5.3/grpc" "-DgRPC_INSTALL=false" "-DgRPC_BUILD_CSHARP_EXT=false" "-DgRPC_BUILD_CODEGEN=false" "-DgRPC_BENCHMARK_PROVIDER=none" "-DgRPC_ZLIB_PROVIDER=package" "-DCMAKE_INSTALL_PREFIX=/Users/fanzeyi/GitHub/project/target/debug/build/grpcio-sys-1925f40788408223/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -stdlib=libc++ -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Debug"
...
-- The ASM compiler identification is AppleClang
-- Found assembler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
...

If you compare the CMake command executed, in 0.1.44 it is specifying -DCMAKE_ASM_COMPILER to /usr/bin/cc (at the very end) while 0.1.42 does not.

src/lib.rs, in Config.build:

        let profile = self.profile.clone().unwrap_or_else(|| {
            match &getenv_unwrap("PROFILE")[..] {
                "bench" | "release" => "Release",
                // currently we need to always use the same CRT for MSVC
                _ if msvc => "Release",
                _ => "Debug",
            }.to_string()
        });

I need debug info for something I’m making now for which I’m using MSVC. Why is this library forcing debug mode for MSVC? As it is, I suppose I’ll be hackily substituting this crate.

I'm on Fedora 32.

This is my FFI crate wrapping a (vendored) C/C++ library: https://github.com/raymanfx/openpnp-capture-rs/tree/master/sys.
I took the linker instruction from the cmake crate examples (see https://github.com/raymanfx/openpnp-capture-rs/blob/master/sys/build.rs#L17).

cargo build says: error: could not find native static library 'openpnp-capture', perhaps an -L flag is missing?.
The full rustc command invoked by cargo looks like this:

Running 'rustc --crate-name openpnp_capture_sys --edition=2018 sys/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata,link -Cembed-bitcode=no -C debuginfo=2 --cfg 'feature="cc"' --cfg 'feature="cmake"' --cfg 'feature="default"' --cfg 'feature="vendor"' -C metadata=705474920d98c929 -C extra-filename=-705474920d98c929 --out-dir /home/chris/work/uni/rs/openpnp-capture/target/debug/deps -C incremental=/home/chris/work/uni/rs/openpnp-capture/target/debug/incremental -L dependency=/home/chris/work/uni/rs/openpnp-capture/target/debug/deps -L native=/home/chris/work/uni/rs/openpnp-capture/target/debug/build/openpnp_capture_sys-d3fa18c1ce2e7611/out -l static=openpnp-capture'

Changing the line in build.rs to: println!("cargo:rustc-link-search=native={}/lib64", out.display()); fixes the issue (that path is where the actual lib resides).

Is this an issue on my side? Surely hardcoding/detecting lib vs lib64 multilib paths cannot be the correct solution here.

So I've been fiddling around with this for a few hours now and can't really figure it out.

I have a component written in C which uses this CMakeLists file which also builds properly. And then I want to link that library in my build.rs which also works.

The problem is that the C component (luadns) depends on libluajit-5.1 and when I build and link via cargo I get undefined reference to 'luaL_newstate' errors (and similar) for every call to the external system library.

I'm a bit at a loss how to fix this so I hope you can help me get this to work ❤️

Currently I'm trying to use this tool to make Facebook's libgraphqlparser, however the process generates a few errors which can be safely ignored. I know this as running a plain cmake . has the intended behavior. I've included the output when using cmake::build from a build.rs file below.

I'm not too familiar with cmake, but my intuition is that the two warnings: one from an optional python example included in the repo and the other from what the message calls policy CMP0042 (which also appears to be a suppressible warning). These two warnings cause an exit code of 2 (again, just my guess) which causes the rust thread to panic.

failed to run custom build command for `graphql-parser v1.0.0 (file:///Users/calebmer/Projects/calebmer/graphql-parser)`
Process didn't exit successfully: `/Users/calebmer/Projects/calebmer/graphql-parser/target/debug/build/graphql-parser-011a4a5e2db17d79/build-script-build` (exit code: 101)
--- stdout
running: "cmake" "/Users/calebmer/Projects/calebmer/graphql-parser/libgraphqlparser" "-DCMAKE_INSTALL_PREFIX=/Users/calebmer/Projects/calebmer/graphql-parser/target/debug/build/graphql-parser-011a4a5e2db17d79/out" "-DCMAKE_C_FLAGS= -O0 -ffunction-sections -fdata-sections -m64 -fPIC" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -O0 -ffunction-sections -fdata-sections -m64 -fPIC" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Debug"
-- Could NOT find BISON: Found unsuitable version "2.3", but required is at least "3" (found /usr/bin/bison)
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/calebmer/Projects/calebmer/graphql-parser/libgraphqlparser
running: "cmake" "--build" "." "--target" "install" "--config" "Debug" "--" "-Wno-dev"

--- stderr
CMake Warning at python/CMakeLists.txt:13 (MESSAGE):
  ctypesgen.py not found; install with pip or easy_install if you want to run
  pythontest.py.


CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   graphqlparser

This warning is for project developers.  Use -Wno-dev to suppress it.

make: *** No rule to make target `install'.  Stop.
thread '<main>' panicked at '
command did not execute successfully, got: exit code: 2

build script failed, must exit now', /Users/calebmer/.multirust/toolchains/stable/cargo/registry/src/github.com-88ac128001ac3a9a/cmake-0.1.16/src/lib.rs:448

Hi, I'm making a wrapper of a CMake project written in C.

I read #90. If I add this line to CMakeLists files, everything works fine (though I don't know why):

install (TARGETS <library_name> DESTINATION .)

However, I'd like to leave the dependent C repository untouched. So, can I build my wrapper crate successfully without changing CMakeLists files? Maybe by changing my build.rs? Thank you!

I'm setting up a brand new computer, so it's time to build rustc! I've installed MSVC 2017, and

When doing so, I get a

couldn't determine visual studio generator
if VisualStudio is installed, however, consider running the appropriate vcvars script before building this crate

If I run vcvars, nothing changes. Same failure.

If I build rustc inside of the Developer Command Prompt, it builds just fine. gets further but fails for other reasons.

This might be a rustc bug bug I figured I'd file it here first... any ideas?

Hi,

This is a pretty big ask, so I am mostly curious if this is something you've thought about.

I am using this crate to build a native lib to then link onto my rust project. This native lib can be used as a shared object, and statically link the private dependencies. However, I wanted to experiment with the link time optimization opportunities, but my compiling and linking the lib statically I am left with plenty of undefined references at link time.

Do you know of a reasonable way to deal with this? Am I totally off track? My thoughts were that ultimately CMake is the thing resolving these dependencies for the native lib and so, it may make sense to lean on CMake to query for these libs in the build.rs file from the CMake target properties?

I would be interested in helping with this change if it seems like a direction that is worth following?

The output of this function is confusing and undocumented.

Based on the code samples in README.md lib.rs, it would appear to be the directory where libs were installed. However, printing its value, I see that it is simply the install prefix (target/debug/build/lammps-sys-96aab2de8377bb22/out), and I need to instead write something like

let dir = cmake.build();
// I don't even know if this is portable...
println!("cargo:rustc-link-search=native={}", dir.join("lib64").display());

I'm not sure what to make of this. I'd call it a bug, but that's assuming that the function is supposed to return the libs dir!

Note: To reproduce what I'm seeing, this isn't exactly minimal, but:

git clone https://github.com/ExpHP/lammps-sys
cd lammps-sys
git checkout 01c3d3bff
git submodule init
git submodule update
cargo build -v

and watch the build script output or linker flags. You'll see the path target/debug/build/lammps-sys-xxxxxxxxx/out/lib64, generated by this line of code, indicating that the return value ended in out as opposed to out/lib or out/lib64.

I see this even on the travis docker image, where much to my chagrin, it actually installs them to lib/. (of course, the linking step fails there!)

I currently can't compile a C++ project with cmake-rs on Windows because it sets CMAKE_BUILD_TYPE, which is not used when CMake generates build files for Visual Studio. This is the error message I get:

error: failed to run custom build command for `cratename v0.1.0 (C:\crate\path)`

Caused by:
  process didn't exit successfully: 'C:\crate\path\debug\build\cratename-hash\build-script-build' (exit code: 101)
--- stderr
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_BUILD_TYPE

thread 'main' panicked at '
command did not execute successfully, got: exit code: 1

build script failed, must exit now', C:\Users\Jonas Platte\.cargo\registry\src\github.com-1eccc6299db9ec823\cmake-0.1.42\src\lib.rs:861:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I am not setting CMAKE_BUILD_TYPE manually. Happens in debug and release.

I ran into a cross-compiling issue where cmake used the host's CMAKE_SYSTEM_PROCESSOR instead of the target's and incorrectly evaluated a condition in the CMakeLists.txt that led to some unsupported compiler flags being used.

After thinking for a bit about how to deal with this issue in general, I can see a couple of solutions:

1. Use a CMAKE_TOOLCHAIN_FILE (#10) as suggested by the CMake CrossCompiling wiki page
2. Set the CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR in the build.rs for each target triplet that I need

The first seems too involved if I only need the second, but the second seems like it should be something not specific to my crate since it only depends directly on the $TARGET.

(Also, let me add as a warning that I am by no means very knowledgeable about CMake, so there may be other reasonable ways to do this.)

I see that there is some support for cross-compiling to certain targets in cmake-rs already (e.g. a9f74a4, #35, #45), but it seems to be done on a case-by-case basis. Plus, there appears to be a large amount of target-specific logic

So, this has led me to wonder if the cmake-rs cross-compiling/target-specific story could be improved and extended to support more targets in a relatively clean way. I'm posting this issue basically to see if there's interest and to discuss ideas. Here are some thoughts on different approaches:

1. Leave cmake-rs mostly untouched and continue to add special cases for various targets.

2. Create a sort of condition matrix to support combinations in a regular way. For example, you might start with host == target and host != target and branch within those into different supported targets.

3. Remove all or most of the target-specific logic and put it into CMAKE_TOOLCHAIN_FILEs, one for each of the different cases supported.

I suppose the latter two options have in common a mapping from Rust target triples to (at least) CMAKE_SYSTEM_NAME/CMAKE_SYSTEM_PROCESSOR pairs, though the Rust one may be more explicit. (I'm certainly not the first person to think of this: rust-lang/rust#50220 (comment))

There are a few other improvements (at least, I think they are) that might also be considered (now or in some distant future):

• Use $CARGO_CFG_TARGET_OS, $CARGO_CFG_TARGET_ARCH, etc. instead of $TARGET
• CI with cross, perhaps in the style of trust
• iOS support (e.g. grpc-sys)

Anyway, these are just some initial thoughts on the matter. Feedback would be appreciated!

CMake 3.14 includes support for Visual Studio 2019 which officially releases in less than two weeks and has had a go-live supported RC out for some time. cmake-rs should support it too.

This version requires the 'new style' selection where the platform selection is separate from the generator name.

Currently, the crate limits the user on what kind of options he can pass to CMake.
I am trying to pass -C path/to/a/cmake/script.cmake(it's a script that speeds-up build-times, I use it for all cmake projects) and it is just impossible to do that with the current API.
I think there should be an option where the user can pass flags himself, whatever he wants.

I was able to get this to work once using CMake install commands, but it would be really nice if there was a minimal working cmake that put a C or C++ library's build output somewhere in the target folder that a Rust project is able to link against, possibly with bindgen. It's just that I can't seem to find documentation and have to work by trial and error.

Any help would be appreciated, thanks!

CMAKE_BUILD_TYPE supports Debug, Release, RelWithDebInfo and MinSizeRel.

If the build type is Rust's release, and -C debuginfo=0 then cmake-rs should use Release, and if -C debuginfo != 0 then it should use RelWithDebInfo.

If the Rust build-type is release but optimizing for size then cmake-rs should use MinSizeRel.

From https://cmake.org/cmake/help/v3.4/generator/MSYS%20Makefiles.html it sounds like it shouldnt be "MSYS Makefile" but rather "MinGW Makefile" when the target is windows. (Getting errors with this currently on Windows)

It would be nice to have a possibility to suppress the cmake output.

Right now, the cmake output is forwarded to cargo. If the output contains non-utf-8 characters, the build fails. This can happen when using e.g. a german msvc that outputs german umlauts in comments.
I have filed an issue for cargo as well, asking them to ignore those lines.

As of version 3.14, cmake has added support for cross compiling iOS (see https://cmake.org/cmake/help/latest/release/3.14.html?highlight=cross#platforms).

This means that -miphone-version-min style parameters get added automatically. This also means that currently when using cmake-rs, these parameters are being added twice, and often with conflicting values.

I've found that in order the support the new system, the following CMAKE variables need to be set:

• CMAKE_SYSTEM_NAME (Set to iOS)
• CMAKE_OSX_ARCHITECTURES (Set to one of: arm64, armv7, armv7s, i386, or x86_64)
• CMAKE_OSX_DEPLOYMENT_TARGET (Could likely be pulled from the IPHONEOS_DEPLOYMENT_TARGET env variable)
• CMAKE_OSX_SYSROOT (Set to either: iphoneos or iphonesimulator)

The target triplets for iOS are:

• aarch64-apple-ios
• armv7-apple-ios
• armv7s-apple-ios
• i386-apple-ios
• x86_64-apple-ios

Additionally, I found that cmake-rs (via cc-rs) is setting the following compiler flags which are not added by cmake:

• -fPIC
• -fembed-bitcode

Note: cmake 3.14 also added support for tvOS and watchOS, but since I don't support them in my own app, I don't know what's required to support them.

I believe #93 ended up causing #95 by accident so I've reverted that change while this is sorted through.

@simlay would you be able to look into this?

Current cmake versions ignore the -DCMAKE_{C|CXX}_{COMPILER|FLAGS} options and warn about them being ignored:

Manually-specified variables were not used by the project:

CMAKE_CXX_COMPILER
CMAKE_CXX_FLAGS

If you are cross compiling with a prefixed compiler, the linking will fail as the build system's compiler is used for the build.

Workaround: Set CC environment variable.

It would be nice to have a new release on crates.io with the latest updates.

I'm relatively new to cmake and to custom rust/cargo build scripts so, correct me if I am wrong. Currently this library doesn't observe the DEBUG environment variable. It may be useful to do this in order support release/debug builds via cargo. I'm suggesting that if DEBUG="true" then set CMAKE_BUILD_TYPE="Debug" else if DEBUG="false" set CMAKE_BUILD_TYPE="Release" else don't set CMAKE_BUILD_TYPE.

My build script fails only on Mac (macOS Mojave 10.14.6). It works fine on linux.
Also tried setting CMAKE_C_COMPILER_WORKS but then I get errors like fatal error: 'stdio.h' file not found.

Here's the relevant part of my build.rs -

    let dst = Config::new("mylib-core")
        .profile("MinSizeRel")
        .define("USE_CURL", "OFF")
        .build_target("mylib")
        .build();

    println!("cargo:rustc-link-search=native={}/build/lib", dst.display());
    println!("cargo:rustc-link-lib=static=mylib");

Here's the output -

error: failed to run custom build command for `mylib-sys v0.1.0 (/Users/dev/mylib-core/rust/mylib-sys)`

Caused by:
  process didn't exit successfully: `/Users/dev/mylib-core/rust/target/debug/build/mylib-sys-f177755e646ed510/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=MACOSX_DEPLOYMENT_TARGET
running: "cmake" "/Users/dev/mylib-core/rust/mylib-sys/mylib-core" "-DCMAKE_OSX_ARCHITECTURES=x86_64" "-DCMAKE_OSX_SYSROOT=macosx" "-DCMAKE_OSX_DEPLOYMENT_TARGET=" "-DUSE_CURL=OFF" "-DDEV_NO_INTRN_PTR=OFF" "-DCMAKE_INSTALL_PREFIX=/Users/dev/mylib-core/rust/target/debug/build/mylib-sys-83508180fe1bf192/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=MinSizeRel"
-- The C compiler identification is AppleClang 10.0.1.10010046
-- The CXX compiler identification is AppleClang 10.0.1.10010046
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
-- Configuring incomplete, errors occurred!
See also "/Users/dev/mylib-core/rust/target/debug/build/mylib-sys-83508180fe1bf192/out/build/CMakeFiles/CMakeOutput.log".
See also "/Users/dev/mylib-core/rust/target/debug/build/mylib-sys-83508180fe1bf192/out/build/CMakeFiles/CMakeError.log".

--- stderr
CMake Error at /usr/local/Cellar/cmake/3.16.1/share/cmake/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/usr/bin/cc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /Users/dev/mylib-core/rust/target/debug/build/mylib-sys-83508180fe1bf192/out/build/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/make cmTC_b026a/fast && /Library/Developer/CommandLineTools/usr/bin/make -f CMakeFiles/cmTC_b026a.dir/build.make CMakeFiles/cmTC_b026a.dir/build
    Building C object CMakeFiles/cmTC_b026a.dir/testCCompiler.c.o
    /usr/bin/cc   -ffunction-sections -fdata-sections -fPIC -m64  -arch x86_64 -isysroot macosx   -o CMakeFiles/cmTC_b026a.dir/testCCompiler.c.o   -c /Users/dev/mylib-core/rust/target/debug/build/mylib-sys-83508180fe1bf192/out/build/CMakeFiles/CMakeTmp/testCCompiler.c
    clang: warning: no such sysroot directory: 'macosx' [-Wmissing-sysroot]
    Linking C executable cmTC_b026a
    /usr/local/Cellar/cmake/3.16.1/bin/cmake -E cmake_link_script CMakeFiles/cmTC_b026a.dir/link.txt --verbose=1
    /usr/bin/cc  -ffunction-sections -fdata-sections -fPIC -m64  -arch x86_64 -isysroot macosx -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/cmTC_b026a.dir/testCCompiler.c.o  -o cmTC_b026a 
    clang: warning: no such sysroot directory: 'macosx' [-Wmissing-sysroot]
    ld: library not found for -lSystem
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    make[1]: *** [cmTC_b026a] Error 1
    make: *** [cmTC_b026a/fast] Error 2
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:39 (project)


thread 'main' panicked at '
command did not execute successfully, got: exit code: 1

build script failed, must exit now', /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.43/src/lib.rs:1104:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

warning: build failed, waiting for other jobs to finish...
error: build failed

Hello
Thanks for the amazing work.

I noticed that the cmake crate tries to parallelize jobs using the NUM_JOBS environment variable. This is currently undocumented. It’s also possible to query the cmake version and pass the —parallel option to cmake (> 3.14), for older cmakes, querying nprocs and equivalents, can make building faster by default.

Currently the crate will automatically inject CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to specify some useful defaults and pass in the target triple to compilers. This works fine for most platforms. Unfortunately this completely breaks the crate when building cmake C dependencies for android.

To use the Android NDK you link in a cmake toolchain file which does all the setup work for you regarding flags and sysroots, you just have to pass in some values describing which Android version and architecture you're building for through some NDK specific CMake variables passed in through the command line. Among the utilities the toolchain provides, one of them is to automatically add the target to the cflags and cxxflags. But because of how building for android works it passes a more specific target triple that is important to the android build process (--target=aarch64-none-linux-android24). It is required to specify the android api level that is being targeted in triple as this will change linker behavior.

The issue is created because the crate force injects --target=aarch64-linux-android into the cflags and cxxflags when building for android and overrides the NDK toolchain file's work. This changes linker behavior (precisely what it changes I do not know) and leads to numerous libraries failing to link (libc++, crtbegin_dynamic, crtend_android).

I believe there needs to be a way to tell the crate to not inject these flags. As a work around you could manually specify the target through the crate's current interface but this just ignores the underlying problem. This issue means using a cross compiling cmake toolchain file is a big dice roll as the crate is currently overriding the target triple provided to the compiler.

[I'm not sure where to file this bug, it's an awkward intersection of things]

In order to use c++11, you need to have a target triple targeting at least x86_64-apple-darwin11. If you specify x86_64-apple-darwin (as cargo does), and don't explicitly specify -stdlib=libc++, it will fail with very obscure error messages that individual symbols in c++11 aren't defined. If you do explicitly specify -stdlib=libc++, it will fail with the useful:

clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)

Either way, if the project being built targeting OSX uses c++11 features, it needs to specify --target=x86_64-apple-darwin11 not x86_64-apple-darwin. Not specifying a target at all also works fine.

It's unclear to me who should be specifying this:

• Cargo doesn't know whether you're going to link against libc++, so shouldn't be making this decision. But maybe it should default to darwin11 unless you specify otherwise, just in case.
• cmake-rs doesn't know whether you're going to link against libc++, so shouldn't be making this decision.
• Individual library writers probably shouldn't have to explicitly write the code to conditionally change the darwin triple any time they use libc++.

Maybe the right answer is to just not set the target triple when compiling for the host target. Maybe cargo should target x86_64-apple-darwin11 by default. Maybe cmake-rs should have a "uses-c++11" boolean or something which you can set to have cmake-rs do the target-twiddling for you. Maybe everyone who uses c++11 and cmake should have to conditionally call .target(...) if the target platform is OSX and they use libc++.

I welcome any thoughts!

I suspect that this is also responsible for #37 - explicitly setting .target("x86_64-apple-darwin11") makes boringssl compile correctly.

I use something like this in my build.rs:

    let dst = cmake::Config::new(Path::new("couchbase-lite-core"))
        .define("DISABLE_LTO_BUILD", "True")
        .define("MAINTAINER_MODE", "False")
        .define("ENABLE_TESTING", "False")
        .build_target("all")
        .build()
        .join("build");

all fine, until user changed CC/CXX environment variable and force rebuild with already
cached cmake build,
then:

cmake ...
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.

and all my settings is gone, like DISABLE_LTO_BUILD, MAINTAINER_MODE etc.

Can cmake-rs detect if CC/CXX changed and rerun cmake twice? So on the second time it get proper values of variables?

The -T LLVM argument with a Visual Studio generator will allow using the clang-cl compiler from LLVM instead of the regular MSVC compilers. It would be good to expose this somehow.

I used cmake::build in my build.rs script, but I noticed that it does the build from scratch every time, even though the underlying files haven't changed. At the top of my output, I see

detected home dir change, cleaning out entire build directory

Is there a way to fix this?

here my build.rs

extern crate cmake;

fn main() {
    let dst = cmake::Config::new("librtmp").build_target("rtmp").build();

    if cfg!(any(windows)) {
        println!("cargo:rustc-link-search=native={}/build/Release", dst.display());
    }
    else {
        println!("cargo:rustc-link-search=native={}/build", dst.display());
    }
    println!("cargo:rustc-link-lib=static=rtmp");
}

if I don't add "/build/Release". I get the following error

error: could not find native static library `rtmp`, perhaps an -L flag is missing?

but it's work fine with it.

and on linux i need to add /build

It's a bug or I do it wrong ?

my cmake

cmake_minimum_required(VERSION 3.0)
project(librtmp)
add_library(rtmp
  STATIC
  rtmp.c
  log.c
  amf.c
  hashswf.c
  parseurl.c
  amf.h
  bytes.h
  dh.h
  dhgroups.h
  handshake.h
  http.h
  log.h
  rtmp_sys.h
  rtmp.h
)
if(WIN32)
  target_link_libraries(rtmp PUBLIC ws2_32)
endif()
target_compile_definitions(rtmp PUBLIC -DNO_CRYPTO)

Trying to build nng:

    let dst = Config::new("nng")
        .generator("Ninja")
        .define("CMAKE_BUILD_TYPE", "Release")
        .define("NNG_TESTS", "OFF")
        .define("NNG_TOOLS", "OFF")
        .build();

Fails:

--- stdout
running: "cmake" "D:\\dev\\runng-sys\\nng" "-Thost=x64" "-G" "Ninja" "-DCMAKE_BUILD_TYPE=Release" "-DNNG_TESTS=OFF" "-DNNG_TOOLS=OFF" "-DCMAKE_INSTALL_PREFIX=D:\\dev\\runng-sys\\target\\debug\\build\\runng-sys-bd05e88b08c12743\\out" "-DCMAKE_C_FLAGS= /nologo /MD" "-DCMAKE_C_COMPILER=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/HostX64/x64/cl.exe" "-DCMAKE_CXX_FLAGS= /nologo /MD" "-DCMAKE_CXX_COMPILER=C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.15.26726/bin/HostX64/x64/cl.exe"
-- Configuring incomplete, errors occurred!
See also "D:/dev/runng-sys/target/debug/build/runng-sys-bd05e88b08c12743/out/build/CMakeFiles/CMakeOutput.log".

--- stderr
CMake Error at CMakeLists.txt:30 (project):
  Generator

    Ninja

  does not support toolset specification, but toolset

    host=x64

  was specified.

Cause is [PR #47] which added -Thost=x64.

Rust version:

D:\dev\runng-sys>rustup show
Default host: x86_64-pc-windows-msvc

stable-x86_64-pc-windows-msvc (default)
rustc 1.28.0 (9634041f0 2018-07-30)

oversight ?

For example Google's BoringSSL can't be build with this crate as it --target isn't a valid cmake command for it.

I don't know how to disable it but the default of --target "install" causes a build error.

This commit broke shaderc-rs on machines with ninja installed: 8c11170
Shaderc-rs issue: google/shaderc-rs#45

In cmake-rs 0.1.19, the Release configuration in the generated CMake build is set to compile with -O0 which is rather unfortunate ;-)

I guess this is a side-effect of 0226679, setting CMAKE_CXX_FLAGS_RELEASE, containing the -O0 generated by the gcc crate.

When compiling a project that has a cmake dependency it'll re-compile the dependency every time cargo is run.

cmake-rs tries to translate cargo settings to cmake settings, but there are two cases where the debuginfio settings are ignored. The first is opt-level=0 + debug=false. This picks the CMake Debug profile, which always has debuginfo on.

The second is opt-level=s + debug=true. This picks MinSizeRel, which always has debuginfo off.

Solving this in the general case looks hard. I have begun trying to do it by running the cmake configure step once with the -LA flags, to list the configured values of CMAKE_C_FLAGS_DEBUG (etc); modify those flags, then run the actual configuration.

I think it's a viable solution, but I haven't quite gotten there: https://github.com/brson/cmake-rs/tree/dev-nodebug

This is a problem in TiKV where we are turning off debuginfo to improve compile times, but RocksDB makes up a huge chunk of that debuginfo. cc tikv/tikv#4711

We could probably solve this one-off in librocksdb_sys, but it would seem better to solve it for everybody.

I'm trying to compile libgit2, which fails on my machine in cmake/VS.

The problem is that my username contains a spacebar ("Forename Lastname", autogenerated by windows). For inspection, press strg+f and search for C:\Users\Forename with highlighting enabled. You'll find partial/incomplete versions of the username string.

I have no idea where to start debugging the problem so help/guidance is appreciated.

    ClCompile:
      C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\HostX86\x64\CL.exe /c /IC:\Users\Forename /Zi /nologo /W1 /WX- /diagnostics:classic /Od /Ob0 /D GIT_SSH /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_258f1.dir\Debug\\" /Fd"cmTC_258f1.dir\Debug\vc141.pdb" /Gd /TC /FC /errorReport:queue  /GL- Lastname\Documents\Projekte\cratestats\target\debug\build\libssh2-sys-65d75e3acd4f00db\out/include "C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\testCCompiler.c"
      include
    c1 : fatal error C1083: Datei (Quelle) kann nicht geöffnet werden: "Lastname\Documents\Projekte\cratestats\target\debug\build\libssh2-sys-65d75e3acd4f00db\out/include": No such file or directory [C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj]
      testCCompiler.c
      Code wird generiert...
    Die Erstellung des Projekts "C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER.

    Fehler beim Buildvorgang.

    "C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj" (Standardziel) (1) ->
    (ClCompile Ziel) ->
      c1 : fatal error C1083: Datei (Quelle) kann nicht geöffnet werden: "Lastname\Documents\Projekte\cratestats\target\debug\build\libssh2-sys-65d75e3acd4f00db\out/include": No such file or directory [C:\Users\Forename Lastname\Documents\Projekte\cratestats\target\debug\build\libgit2-sys-157e0f5b905e5579\out\build\CMakeFiles\CMakeTmp\cmTC_258f1.vcxproj]

It looks like CMake is configured and built(null build) even when it's not changed from the previous build. I guess it's good to have it cached?

https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md

With VS 2017 the path to MSBuild is no longer in the same location. See https://stackoverflow.com/questions/328017/path-to-msbuild

Since cmake-rs and gcc-rs both need this info, seems like cmake should defer to gcc.

Recently, I am working on snmalloc-rs to
make it support Android cross compilation.

SchrodingerZhu/snmalloc-rs@09726c0

It seems that target_os="android" is not working here. Yet, current solution can only compile the library itself. When another Android binary crate depends on this crate, the target static library compiled by cmake does not have the right architecture.

The Config builder sets CMAKE_C_FLAGS to add things like -fPIC, but does not set CMAKE_CXX_FLAGS in the same way so C++ builds fail to link. Same deal with CMAKE_C_COMPILER.