corrosion-rs / corrosion Goto Github PK

I get the following error when running cmake:

This might not be an issue, i do not know if this git supports Mac OS.

Configuration:
cmake version 3.17.0
Mac OS 10.15.2 (19C57)

Any idea how to solve this?

We really aught to apply global and directory flags to the link line in cargo. Examples include, but are not limited to:

• CMAKE_<lang>_FLAGS
• CMAKE_SHARED_LINKER_FLAGS
• CMAKE_EXE_LINKER_FLAGS

We're actually probably kind of broken if we don't do this.

The right thing to do is probably to issue a warning if we detect that the user is trying to link a C++ library into a Rust executable that isn't compiled with PIC.

add_custom_target calls need to set the BYPRODUCTS to the cargo-build_${target_name} targets for the Ninja generator to work.

Currently we're using absolute paths - derived from target_directory property on the metadata.

The main reason corrosion-generator exists is that it makes it easier to parse the cargo metadata output. CMake 3.19 adds a new string(JSON ...) command that makes parsing JSON much easier.

We'd definitely need to keep corrosion-generator for pre 3.19 targets, but potentially for 3.19 and later targets, it could be eliminated, making it much faster to use as a subdirectory.

Cross-compiling for Android is now working for basic scenarios, but there should probably be a test for it in CI.

If a Rust static library depends on native static libraries, it doesn't need to wait for those native static libraries to be built before the crate is built. Therefore, we can safely apply OPTIMIZE_DEPENDENCIES. Available only on CMake 3.19+.

https://cmake.org/cmake/help/v3.0/command/add_test.html

This is related to #3 - we need to more aggressively configure the generated target-dirs.

This makes it easier/more correct to specify BYPRODUCTS.

RE: #60 (comment)

Currently bins and libs are just left in the cargo build tree, which is out of sync with where CMake-native artifacts are placed. Artifacts should be placed in CMAKE_CURRENT_BINARY_DIR. Placement should also respect "OUTPUT_DIRECTORY" properties:

• ARCHIVE_OUTPUT_DIRECTORY
• LIBRARY_OUTPUT_DIRECTORY
• RUNTIME_OUTPUT_DIRECTORY
• PDB_OUTPUT_DIRECTORY
• COMPILE_PDB_OUTPUT_DIRECTORY

Cross-compiling seems to be broken. Visual Studio is the most obviously broken, but I haven't
tested cross-compiling in a Unix context yet. Should check both.

RE: #60

I decided to give a new try to this project, however, how is it possible to use cross compiling if the required CMake version for corrosion is 3.12 but Android's max available CMake is 3.10.2?

• Change crate, module, and library names
• Change the GitHub project name
• Update README
• Change function names

I tried adding

set(RUSTUP_TOOLCHAIN "nightly-x86_64-unknown-linux-gnu")

to my CMakeLists.txt file, but that doesn't seem to have any effect, it's still using the stable toolchain.

EDIT: I think compile-time derivation of the link requirements is intractible. It would force CMake to re-determine the graph at build time, which is almost certainly not possible. Instead, we should just emit a warning if we notice that rustc lists a static library dependency that has not been listed in the CMake file.

Things to do:

• Capture the stdlib static library dependencies on all supported platforms
• Add a NO_STD option (or derive this from the crate, if possible) to add_crate that opts out of linking against those static libraries
  • If Cargo allowed this to be specified in the TOML file, could be automatically derived
• Capture the results of rustc --print=native-static-libs

Corrosion should offer the possibility to import crates using a Cargo.toml from a workspace. If that is already possible, it should be mentioned in the documentation. If not, a ToDo should be added.

Currently corrosion-generator is used via cargo run when bootstrapping (e.g. via submodule or FetchContent). Instead, we should build it first, and then just use the executable directly. Additionally, forward the build output for corrosion-generator during configuration so the user can see something is going on.

Currently corrosion_install only works with executables.

There were no instructions os I simply cloned this repo along my CMakeLists.txt like this:

CMakeLists.txt cmake-cargo Cargo.toml build

This is the CMakeLists.txt:

cmake_minimum_required (VERSION 3.10)
project(CargoTest LANGUAGES CXX)

list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake-cargo/cmake")
set(CARGO_DEV_MODE ON CACHE INTERNAL "")

include(Cargo)

add_crate(Cargo.toml)

it should build my Cargo.toml, shouldn't it?

so inside build I did cmake ../

root@e85658e77489:/workspaces/smoltcp_openvpn_bridge/build# cmake ../
-- The CXX compiler identification is GNU 7.5.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Rust Target: x86_64-unknown-linux-gnu
-- Found Cargo: /root/.cargo/bin/cargo (found version "1.44.0") 
-- Defaulting Cargo to build debug
-- Running in cmake-cargo dev mode
-- Configuring done
CMake Error at cmake-cargo/cmake/Cargo.cmake:36 (add_custom_target):
  Error evaluating generator expression:

    $<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_smoltcp_cpp_interface_rust,CARGO_LINK_LIBRARIES>>

  Expression did not evaluate to a known generator expression
Call Stack (most recent call first):
  build/CMakeFiles/cmake-cargo/smoltcp_openvpn_bridge.dir/cargo-build.cmake:3 (_add_cargo_build)
  cmake-cargo/cmake/Cargo.cmake:115 (include)
  CMakeLists.txt:9 (add_crate)


CMake Error at cmake-cargo/cmake/Cargo.cmake:36 (add_custom_target):
  Error evaluating generator expression:

    $<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_smoltcp_cpp_interface_rust,CARGO_LINK_DIRECTORIES>>

  Expression did not evaluate to a known generator expression
Call Stack (most recent call first):
  build/CMakeFiles/cmake-cargo/smoltcp_openvpn_bridge.dir/cargo-build.cmake:3 (_add_cargo_build)
  cmake-cargo/cmake/Cargo.cmake:115 (include)
  CMakeLists.txt:9 (add_crate)


CMake Error at cmake-cargo/cmake/Cargo.cmake:36 (add_custom_target):
  Error evaluating generator expression:

    $<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_smoltcp_cpp_interface_rust,CARGO_LINK_LIBRARIES>>

  Expression did not evaluate to a known generator expression
Call Stack (most recent call first):
  build/CMakeFiles/cmake-cargo/smoltcp_openvpn_bridge.dir/cargo-build.cmake:3 (_add_cargo_build)
  cmake-cargo/cmake/Cargo.cmake:115 (include)
  CMakeLists.txt:9 (add_crate)


CMake Error at cmake-cargo/cmake/Cargo.cmake:36 (add_custom_target):
  Error evaluating generator expression:

    $<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_smoltcp_cpp_interface_rust,CARGO_LINK_DIRECTORIES>>

  Expression did not evaluate to a known generator expression
Call Stack (most recent call first):
  build/CMakeFiles/cmake-cargo/smoltcp_openvpn_bridge.dir/cargo-build.cmake:3 (_add_cargo_build)
  cmake-cargo/cmake/Cargo.cmake:115 (include)
  CMakeLists.txt:9 (add_crate)


CMake Error at cmake-cargo/cmake/Cargo.cmake:36 (add_custom_target):
  Error evaluating generator expression:

    $<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_smoltcp_cpp_interface_rust,CARGO_LINK_LIBRARIES>>

  Expression did not evaluate to a known generator expression
Call Stack (most recent call first):
  build/CMakeFiles/cmake-cargo/smoltcp_openvpn_bridge.dir/cargo-build.cmake:3 (_add_cargo_build)
  cmake-cargo/cmake/Cargo.cmake:115 (include)
  CMakeLists.txt:9 (add_crate)


CMake Error at cmake-cargo/cmake/Cargo.cmake:36 (add_custom_target):
  Error evaluating generator expression:

    $<GENEX_EVAL:$<TARGET_PROPERTY:cargo-build_smoltcp_cpp_interface_rust,CARGO_LINK_DIRECTORIES>>

  Expression did not evaluate to a known generator expression
Call Stack (most recent call first):
  build/CMakeFiles/cmake-cargo/smoltcp_openvpn_bridge.dir/cargo-build.cmake:3 (_add_cargo_build)
  cmake-cargo/cmake/Cargo.cmake:115 (include)
  CMakeLists.txt:9 (add_crate)


-- Generating done
-- Build files have been written to: /workspaces/smoltcp_openvpn_bridge/build

I'm looking into building some ROS nodes using a combination of corrosion and https://github.com/adnanademovic/rosrust

The examples show linking cpp and rust together but what I want to do is use corrosion to build my rust binary and then refer to it elsewhere in my cmake file (for instance in an install step).

Currently we only import the primary target of the crate, ignoring the fact that a crate can export multiple bins and libs. So we should really import the primary target as foo::foo, and then import alternate targets as, for example, foo::bar. Related to #57, #11, #12

I've been using 3.0, but I don't know if this is accurate to the features we're using.

There should be an option to specify the toolchain to use. Otherwise, use and cache the default toolchain.

There should be a way to filter the imported crates from a workspace.

Something like:

corrosion_import_crate(
    MANIFEST_PATH Cargo.toml
    CRATES foo)

cc @ogoffart

EDIT: Additionally, corrosion_import_crate should only import the crates in the target manifest, not for the whole workspace.

When installing CMake using the instructions from the README, Corrosion is installed to /usr/local/Corrosion on a GNU/inux system. However, the install prefix should be /usr/local so that FindPackage` discovers the package configuration.

This is specifically for "build tools" - basically, if you're cross-compiling, you still want your build tools to build for the host architecture. Similarly to cargo build scripts, this will probably mean just not using the --target flag, which generally gives the correct result for the host architecture - should be the same as the toolchain architecture.

Considerations: Potentially not allowing you to call corrosion_link_libraries on these imported crates? Or only for libraries that aren't CMake targets, perhaps? I don't know, need to consider this more.

Hi!

Im trying to compile my c bindings for rust, and this works great!
The only downside is an issue with my workspace setup
This is how it looks:

project
--> /bindings
----> /c
------ Cargo.toml
------ CMakeLists.txt
--> /member_a
--> /member_b
-- Cargo.toml

Now the Cargo.toml in /bindings/c imports the other cargo like this: project = { path = "../../"}
When I try to build using cmake, i get a ton of use of undeclared type XYZ
Only when I change the import to one in git = "", it works

Any way to get around this?

Thank you!
Brord

Currently, RUSTUP_TOOLCHAIN requires you to append the entire host target triple (e.g. RUSTUP_TOOLCHAIN=nightly-x86_64-pc-windows-msvc). rustup show can be used to look up the "Default Host". If we fail to find a a toolchain with the precise name, we should append the default host and search again.

When I try to build my project with Corrosion and the Ninja Multi-Config generator, I get a mesage like this:

$ cd build && cmake Ninja -G "Multi-Config" ..
[…]
-- Using Corrosion as a subdirectory
-- Configuring done
-- Generating done
-- Build files have been written to: /some/path/build

$ cmake --build . --
ninja: error: 'Debug/cargo/build/x86_64-unknown-linux-gnu/debug/libfoo.a', needed by 'src/bar/Debug/bar', missing and no known rule to make it

If I use -G Ninja, it works. I had this issue with single-conf vs. multi-conf. in my project as well. It usually boils doin to a few generator expressions at places where paths are constructed.

Thanks :-)

It seems like we don't actually need the build-script crate - everything we need should be doable with CARGO_TARGET__RUSTFLAGS.

add_crate should include an option to specify whether each example is its own target or all examples are a single target.

Needed for knl-specific builds

This is common for code generators - write a tool that lives in tree, then use that tool to generate code as part of the build. Will be used for certain configurations of bindgen support, as well.

RE: #60

Currently we generate a massive matrix of configurations (rust toolchain, cmake version, platform, etc.) and bootstrap all of Corrosion. Really what I should do is just a handful of bootstrap jobs and then run faster tests using the install from those bootstrap tests. There will still be explicit tests for using corrosion as a submodule.

Need to switch HINTS in find_program to PATHS.

executables includes tests and examples.

No reason to have targets for pure Rust crates - they don't integrate into CMake ecosystem