Stowage/clamav
2
0
Fork 0
mirror of https://github.com/Cisco-Talos/clamav.git synced 2025-10-19 10:23:17 +00:00
Code Issues Projects Releases Packages Wiki Activity
clamav/cmake/FindRust.cmake

486 lines
20 KiB
CMake
Raw Normal View History

CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
# Find the Rust toolchain and add the `add_rust_library()` API to build Rust
# libraries.
#
Bump copyright for 2023
2023-02-07 19:35:18 -08:00
# Copyright (C) 2021-2023 Cisco Systems, Inc. and/or its affiliates. All rights reserved.
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
# Author: Micah Snyder
# To see this in a sample project, visit: https://github.com/micahsnyder/cmake-rust-demo
#
# Code to set the Cargo arguments was lifted from:
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# https://github.com/Devolutions/CMakeRust
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
# This Module defines the following variables:
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# - <program>_FOUND - True if the program was found
# - <program>_EXECUTABLE - path of the program
# - <program>_VERSION - version number of the program
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
# ... for the following Rust toolchain programs:
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# - cargo
# - rustc
# - rustup
# - rust-gdb
# - rust-lldb
# - rustdoc
# - rustfmt
# - bindgen
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
# Callers can make any program mandatory by setting `<program>_REQUIRED` before
# the call to `find_package(Rust)`
#
# Eg:
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# find_package(Rust REQUIRED)
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# This module provides the following functions:
# =============================================
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# `add_rust_library()`
# --------------------
#
# This allows a caller to create a Rust static library
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# target which you can link to with `target_link_libraries()`.
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# Your Rust static library target will itself depend on the native static libs
# you get from `rustc --crate-type staticlib --print=native-static-libs /dev/null`
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# The CARGO_CMD environment variable will be set to "BUILD" so you can tell
# it's not building the unit tests inside your (optional) `build.rs` file.
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# Example `add_rust_library()` usage:
CMake-Rust: Only execute cbindgen for build, not tests Generate c-bindings header in build (binary) directory, not source directory (if different).
2022-01-03 16:49:45 -08:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# ```cmake
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
# add_rust_library(TARGET yourlib
# SOURCE_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}")
# BINARY_DIRECTORY "${CMAKE_BINARY_DIR}")
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# add_library(YourProject::yourlib ALIAS yourlib)
#
# add_executable(yourexe)
# target_link_libraries(yourexe YourProject::yourlib)
# ```
#
# If your library has unit tests AND your library does NOT depend on your C
# librar(ies), you can use `add_rust_library()` to build your library and unit
# tests at the same time. Just pass `PRECOMPILE_TESTS TRUE` to add_rust_library.
# This should make it so when you run the tests, they don't have to compile
# during the test run.
#
# If your library does have C dependencies, you can still precompile the tests
# by passing `PRECOMPILE_TESTS TRUE`, with `add_rust_test()` instead.
# It will be slower because it will have to compile the C stuff first,
# then compile the Rust stuff from scratch. See below.
CMake-Rust: Only execute cbindgen for build, not tests Generate c-bindings header in build (binary) directory, not source directory (if different).
2022-01-03 16:49:45 -08:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# `add_rust_test()`
# -----------------
CMake-Rust: Only execute cbindgen for build, not tests Generate c-bindings header in build (binary) directory, not source directory (if different).
2022-01-03 16:49:45 -08:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# This allows a caller to run `cargo test` for a specific Rust target as a CTest
# test.
CMake-Rust: Only execute cbindgen for build, not tests Generate c-bindings header in build (binary) directory, not source directory (if different).
2022-01-03 16:49:45 -08:00
#
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# The CARGO_CMD environment variable will be set to "TEST" so you can tell
# it's not building the unit tests inside your (optional) `build.rs` file.
CMake-Rust: Only execute cbindgen for build, not tests Generate c-bindings header in build (binary) directory, not source directory (if different).
2022-01-03 16:49:45 -08:00
#
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# Example `add_rust_test()` usage:
CMake-Rust: Only execute cbindgen for build, not tests Generate c-bindings header in build (binary) directory, not source directory (if different).
2022-01-03 16:49:45 -08:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# ```cmake
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
# add_rust_test(NAME yourlib
# SOURCE_DIRECTORY "${CMAKE_SOURCE_DIR}/path/to/yourlib"
# BINARY_DIRECTORY "${CMAKE_BINARY_DIR}"
# )
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# set_property(TEST yourlib PROPERTY ENVIRONMENT ${ENVIRONMENT})
# ```
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
#
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
# Experimental: Precompile the Tests Executable
# ~~~~~~~~~~~~
# This feature will cause install failures if you `sudo make install` because
# it will recompile the test executable with sudo and Cargo is likely to fail to
# run with sudo.
# This cannot be fixed unless we can predetermine the test exeecutable OUTPUT
# filepath. See: https://github.com/rust-lang/cargo/issues/1924
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# If your library has unit tests AND your library DOES depend on your C
# libraries, you can precompile the unit tests application with some extra
# parameters to `add_rust_test()`:
# - `PRECOMPILE_TESTS TRUE`
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
# - `PRECOMPILE_DEPENDS <the CMake target name for your C library dependency>`
# - `PRECOMPILE_ENVIRONMENT <a linked list of environment vars to build the Rust lib>`
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
#
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
# The `PRECOMPILE_DEPENDS` option is required so CMake will build the C library first.
# The `PRECOMPILE_ENVIRONMENT` option is required for use in your `build.rs` file so you
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# can tell rustc how to link to your C library.
#
# For example:
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# ```cmake
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
# add_rust_test(NAME yourlib
# SOURCE_DIRECTORY "${CMAKE_SOURCE_DIR}/yourlib"
# BINARY_DIRECTORY "${CMAKE_BINARY_DIR}"
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# PRECOMPILE_TESTS TRUE
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
# PRECOMPILE_DEPENDS ClamAV::libclamav
# PRECOMPILE_ENVIRONMENT "${ENVIRONMENT}"
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# )
# set_property(TEST yourlib PROPERTY ENVIRONMENT ${ENVIRONMENT})
# ```
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# `add_rust_executable()`
# -----------------------
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
#
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# This allows a caller to create a Rust executable target.
#
# Example `add_rust_executable()` usage:
#
# ```cmake
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
# add_rust_executable(TARGET yourexe
# SOURCE_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
# BINARY_DIRECTORY "${CMAKE_BINARY_DIR}"
# )
# add_executable(YourProject::yourexe ALIAS yourexe)
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
# ```
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
if(NOT DEFINED CARGO_HOME)
if(WIN32)
set(CARGO_HOME "$ENV{USERPROFILE}/.cargo")
else()
set(CARGO_HOME "$ENV{HOME}/.cargo")
endif()
endif()
include(FindPackageHandleStandardArgs)
function(find_rust_program RUST_PROGRAM)
find_program(${RUST_PROGRAM}_EXECUTABLE ${RUST_PROGRAM}
HINTS "${CARGO_HOME}"
PATH_SUFFIXES "bin"
)
if(${RUST_PROGRAM}_EXECUTABLE)
execute_process(COMMAND "${${RUST_PROGRAM}_EXECUTABLE}" --version
OUTPUT_VARIABLE ${RUST_PROGRAM}_VERSION_OUTPUT
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
ERROR_VARIABLE ${RUST_PROGRAM}_VERSION_ERROR
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
RESULT_VARIABLE ${RUST_PROGRAM}_VERSION_RESULT
)
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
if(NOT ${${RUST_PROGRAM}_VERSION_RESULT} EQUAL 0)
message(STATUS "Rust tool `${RUST_PROGRAM}` not found: Failed to determine version.")
unset(${RUST_PROGRAM}_EXECUTABLE)
else()
string(REGEX
MATCH "[0-9]+\\.[0-9]+(\\.[0-9]+)?(-nightly)?"
${RUST_PROGRAM}_VERSION "${${RUST_PROGRAM}_VERSION_OUTPUT}"
)
set(${RUST_PROGRAM}_VERSION "${${RUST_PROGRAM}_VERSION}" PARENT_SCOPE)
message(STATUS "Rust tool `${RUST_PROGRAM}` found: ${${RUST_PROGRAM}_EXECUTABLE}, ${${RUST_PROGRAM}_VERSION}")
endif()
mark_as_advanced(${RUST_PROGRAM}_EXECUTABLE ${RUST_PROGRAM}_VERSION)
else()
if(${${RUST_PROGRAM}_REQUIRED})
message(FATAL_ERROR "Rust tool `${RUST_PROGRAM}` not found.")
else()
message(STATUS "Rust tool `${RUST_PROGRAM}` not found.")
endif()
endif()
endfunction()
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
function(cargo_vendor)
set(options)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(oneValueArgs TARGET SOURCE_DIRECTORY BINARY_DIRECTORY)
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
cmake_parse_arguments(ARGS "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
if(NOT EXISTS ${ARGS_SOURCE_DIRECTORY}/.cargo/config.toml)
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
# Vendor the dependencies and create .cargo/config.toml
# Vendored dependencies will be used during the build.
# This will allow us to package vendored dependencies in source tarballs
# for online builds when we run `cpack --config CPackSourceConfig.cmake`
message(STATUS "Running `cargo vendor` to collect dependencies for ${ARGS_TARGET}. This may take a while if the local crates.io index needs to be updated ...")
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
make_directory(${ARGS_SOURCE_DIRECTORY}/.cargo)
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
execute_process(
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
COMMAND ${CMAKE_COMMAND} -E env "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" ${cargo_EXECUTABLE} vendor ".cargo/vendor"
WORKING_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
OUTPUT_VARIABLE CARGO_VENDOR_OUTPUT
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
ERROR_VARIABLE CARGO_VENDOR_ERROR
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
RESULT_VARIABLE CARGO_VENDOR_RESULT
)
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
if(NOT ${CARGO_VENDOR_RESULT} EQUAL 0)
message(FATAL_ERROR "Failed!\n${CARGO_VENDOR_ERROR}")
else()
message("Success!")
endif()
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
write_file(${ARGS_SOURCE_DIRECTORY}/.cargo/config.toml "
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
[source.crates-io]
replace-with = \"vendored-sources\"
[source.vendored-sources]
directory = \".cargo/vendor\"
"
)
endif()
endfunction()
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
function(add_rust_executable)
set(options)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(oneValueArgs TARGET SOURCE_DIRECTORY BINARY_DIRECTORY)
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
cmake_parse_arguments(ARGS "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
if(WIN32)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(OUTPUT "${ARGS_BINARY_DIRECTORY}/${RUST_COMPILER_TARGET}/${CARGO_BUILD_TYPE}/${ARGS_TARGET}.exe")
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
else()
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(OUTPUT "${ARGS_BINARY_DIRECTORY}/${RUST_COMPILER_TARGET}/${CARGO_BUILD_TYPE}/${ARGS_TARGET}")
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
endif()
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
file(GLOB_RECURSE EXE_SOURCES "${ARGS_SOURCE_DIRECTORY}/*.rs")
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
set(MY_CARGO_ARGS ${CARGO_ARGS})
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
list(APPEND MY_CARGO_ARGS "--target-dir" ${ARGS_BINARY_DIRECTORY})
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
list(JOIN MY_CARGO_ARGS " " MY_CARGO_ARGS_STRING)
# Build the executable.
add_custom_command(
OUTPUT "${OUTPUT}"
CMake: Allow passing in custom RUSTFLAGS A user building clamav may now set the RUSTFLAGS CMake variable if additional options such as `--verbose` are desired. E.g. cmake .. -D RUSTFLAGS="--verbose" See `rustc --help` for more details.
2023-03-22 16:39:04 -06:00
COMMAND ${CMAKE_COMMAND} -E env "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS}
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
WORKING_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
DEPENDS ${EXE_SOURCES}
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
COMMENT "Building ${ARGS_TARGET} in ${ARGS_BINARY_DIRECTORY} with:\n\t ${cargo_EXECUTABLE} ${MY_CARGO_ARGS_STRING}")
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
# Create a target from the build output
add_custom_target(${ARGS_TARGET}_target
DEPENDS ${OUTPUT})
# Create an executable target from custom target
add_custom_target(${ARGS_TARGET} ALL DEPENDS ${ARGS_TARGET}_target)
# Specify where the executable is
set_target_properties(${ARGS_TARGET}
PROPERTIES
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
IMPORTED_LOCATION "${OUTPUT}"
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
)
# Vendor the dependencies, if desired
if(VENDOR_DEPENDENCIES)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
cargo_vendor(TARGET "${ARGS_TARGET}"
SOURCE_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
BINARY_DIRECTORY "${ARGS_BINARY_DIRECTORY}"
)
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
endif()
endfunction()
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
function(add_rust_library)
set(options)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(oneValueArgs TARGET SOURCE_DIRECTORY BINARY_DIRECTORY PRECOMPILE_TESTS)
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
cmake_parse_arguments(ARGS "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
if(WIN32)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(OUTPUT "${ARGS_BINARY_DIRECTORY}/${RUST_COMPILER_TARGET}/${CARGO_BUILD_TYPE}/${ARGS_TARGET}.lib")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
else()
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
set(OUTPUT "${ARGS_BINARY_DIRECTORY}/${RUST_COMPILER_TARGET}/${CARGO_BUILD_TYPE}/lib${ARGS_TARGET}.a")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
endif()
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
file(GLOB_RECURSE LIB_SOURCES "${ARGS_SOURCE_DIRECTORY}/*.rs")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
set(MY_CARGO_ARGS ${CARGO_ARGS})
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
if(ARGS_PRECOMPILE_TESTS)
list(APPEND MY_CARGO_ARGS "--tests")
endif()
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
list(APPEND MY_CARGO_ARGS "--target-dir" ${ARGS_BINARY_DIRECTORY})
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
list(JOIN MY_CARGO_ARGS " " MY_CARGO_ARGS_STRING)
Integrate cbindgen via build.rs
2021-11-29 17:24:39 -08:00
# Build the library and generate the c-binding
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
if("${CMAKE_OSX_ARCHITECTURES}" MATCHES "^(arm64;x86_64|x86_64;arm64)$")
Integrate cbindgen via build.rs
2021-11-29 17:24:39 -08:00
add_custom_command(
OUTPUT "${OUTPUT}"
CMake: Allow passing in custom RUSTFLAGS A user building clamav may now set the RUSTFLAGS CMake variable if additional options such as `--verbose` are desired. E.g. cmake .. -D RUSTFLAGS="--verbose" See `rustc --help` for more details.
2023-03-22 16:39:04 -06:00
COMMAND ${CMAKE_COMMAND} -E env "CARGO_CMD=build" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" "MAINTAINER_MODE=${MAINTAINER_MODE}" "RUSTFLAGS=${RUSTFLAGS}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS} --target=x86_64-apple-darwin
COMMAND ${CMAKE_COMMAND} -E env "CARGO_CMD=build" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" "MAINTAINER_MODE=${MAINTAINER_MODE}" "RUSTFLAGS=${RUSTFLAGS}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS} --target=aarch64-apple-darwin
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
COMMAND ${CMAKE_COMMAND} -E make_directory "${ARGS_BINARY_DIRECTORY}/${RUST_COMPILER_TARGET}/${CARGO_BUILD_TYPE}"
CMake: Allow passing in custom RUSTFLAGS A user building clamav may now set the RUSTFLAGS CMake variable if additional options such as `--verbose` are desired. E.g. cmake .. -D RUSTFLAGS="--verbose" See `rustc --help` for more details.
2023-03-22 16:39:04 -06:00
COMMAND lipo -create ${ARGS_BINARY_DIRECTORY}/x86_64-apple-darwin/${CARGO_BUILD_TYPE}/lib${ARGS_TARGET}.a ${ARGS_BINARY_DIRECTORY}/aarch64-apple-darwin/${CARGO_BUILD_TYPE}/lib${ARGS_TARGET}.a -output "${OUTPUT}"
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
WORKING_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
Integrate cbindgen via build.rs
2021-11-29 17:24:39 -08:00
DEPENDS ${LIB_SOURCES}
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
COMMENT "Building ${ARGS_TARGET} in ${ARGS_BINARY_DIRECTORY} with: ${cargo_EXECUTABLE} ${MY_CARGO_ARGS_STRING}")
CMake: link openssl 3.x with clamsubmit on macOS When switching to openssl 3.x, linking with clamsubmit fails with undefined openssl symbols. The error message from Xcode is crazy obtuse: ld: initializer '_OPENSSL_cpuid_setup' is >4GB from start of image in 'anon' from /Users/clamav_jenkins_svc/clamav-mussels-cookbook/test/install-x86_64/lib/libcrypto.a(libcrypto-lib-x86_64cpuid.o) clang: error: linker command failed with exit code 1 (use -v to see invocation) Anyhow... It seems that we must explicitly link clamsubmit with openssl now in order for this to work. In addition to this change, I also found that the CMake FindRust.cmake module breaks the ability to build specifically for just x86_64 or arm64 (i.e. possibly cross-compiling. This commit includes a change to accommodate that scenario.
2023-07-11 09:39:57 -07:00
elseif("${CMAKE_OSX_ARCHITECTURES}" MATCHES "^(arm64)$")
add_custom_command(
OUTPUT "${OUTPUT}"
COMMAND ${CMAKE_COMMAND} -E env "CARGO_CMD=build" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" "MAINTAINER_MODE=${MAINTAINER_MODE}" "RUSTFLAGS=${RUSTFLAGS}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS} --target=aarch64-apple-darwin
WORKING_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
DEPENDS ${LIB_SOURCES}
COMMENT "Building ${ARGS_TARGET} in ${ARGS_BINARY_DIRECTORY} with: ${cargo_EXECUTABLE} ${MY_CARGO_ARGS_STRING}")
elseif("${CMAKE_OSX_ARCHITECTURES}" MATCHES "^(x86_64)$")
add_custom_command(
OUTPUT "${OUTPUT}"
COMMAND ${CMAKE_COMMAND} -E env "CARGO_CMD=build" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" "MAINTAINER_MODE=${MAINTAINER_MODE}" "RUSTFLAGS=${RUSTFLAGS}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS} --target=x86_64-apple-darwin
COMMAND ${CMAKE_COMMAND} -E make_directory "${ARGS_BINARY_DIRECTORY}/${RUST_COMPILER_TARGET}/${CARGO_BUILD_TYPE}"
WORKING_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
DEPENDS ${LIB_SOURCES}
COMMENT "Building ${ARGS_TARGET} in ${ARGS_BINARY_DIRECTORY} with: ${cargo_EXECUTABLE} ${MY_CARGO_ARGS_STRING}")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
else()
Integrate cbindgen via build.rs
2021-11-29 17:24:39 -08:00
add_custom_command(
OUTPUT "${OUTPUT}"
CMake: Allow passing in custom RUSTFLAGS A user building clamav may now set the RUSTFLAGS CMake variable if additional options such as `--verbose` are desired. E.g. cmake .. -D RUSTFLAGS="--verbose" See `rustc --help` for more details.
2023-03-22 16:39:04 -06:00
COMMAND ${CMAKE_COMMAND} -E env "CARGO_CMD=build" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" "MAINTAINER_MODE=${MAINTAINER_MODE}" "RUSTFLAGS=${RUSTFLAGS}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS}
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
WORKING_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
Integrate cbindgen via build.rs
2021-11-29 17:24:39 -08:00
DEPENDS ${LIB_SOURCES}
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
COMMENT "Building ${ARGS_TARGET} in ${ARGS_BINARY_DIRECTORY} with: ${cargo_EXECUTABLE} ${MY_CARGO_ARGS_STRING}")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
endif()
# Create a target from the build output
add_custom_target(${ARGS_TARGET}_target
DEPENDS ${OUTPUT})
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
# Create a static imported library target from custom target
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
add_library(${ARGS_TARGET} STATIC IMPORTED GLOBAL)
add_dependencies(${ARGS_TARGET} ${ARGS_TARGET}_target)
target_link_libraries(${ARGS_TARGET} INTERFACE ${RUST_NATIVE_STATIC_LIBS})
# Specify where the library is and where to find the headers
set_target_properties(${ARGS_TARGET}
PROPERTIES
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
IMPORTED_LOCATION "${OUTPUT}"
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
INTERFACE_INCLUDE_DIRECTORIES "${ARGS_SOURCE_DIRECTORY};${ARGS_BINARY_DIRECTORY}"
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
)
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
# Vendor the dependencies, if desired
if(VENDOR_DEPENDENCIES)
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
cargo_vendor(TARGET "${ARGS_TARGET}"
SOURCE_DIRECTORY "${ARGS_SOURCE_DIRECTORY}"
BINARY_DIRECTORY "${ARGS_BINARY_DIRECTORY}")
Add cargo vendor feature Vendoring crate dependencies is required for offline builds. Some packaging systems require that builds can be performed offline. This feature enabled vendoring crates at configure time which are then included in in CPack source packaging.
2021-04-22 17:35:15 -07:00
endif()
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
endfunction()
function(add_rust_test)
set(options)
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
set(oneValueArgs NAME SOURCE_DIRECTORY BINARY_DIRECTORY PRECOMPILE_TESTS PRECOMPILE_DEPENDS)
set(multiValueArgs PRECOMPILE_ENVIRONMENT)
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
cmake_parse_arguments(ARGS "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
Add Rust logging module unit test & integrate with CMake / CTest Add a basic unit test for the new libclamav_rust `logging.rs` module. This test simply initializes logging and then prints out a message with each of the `log` macros. Also set the Rust edition to 2018 because the default is the 2015 edition in which using external crates is very clunky. For the Rust test support in CMake this commit adds support for cross-compiling the Rust tests. Rust tests must be built for the same LLVM triple (target platform) as the rest of the project. In particular this is needed to build both x64 and x86 packages on a 64bit Windows host. For Alpine, we observed that the LLVM triple for the host platform tools may be either: - x86_64-unknown-linux-musl, or - x86_64-alpine-linux-musl To support it either way, we look up the host triple with `rustc -vV` and use that if the musl libc exists. This is a big hacky and unfortunately means that we probably can't cross-compile to other platforms when running on a musl libc host. There are probably improvements to be made to improve cross compiling support. The Rust test programs must link with libclamav, libclammspack, and possibly libclamunrar_iface and libclamunrar plus all of the library dependencies for those libraries. To do this, we pass the path of each library in environment variables when building the libclamav_rust unit test program. Within `libclamav_rust/build.rs`, we read those environment variables. If set, we parse each into library path and name components to use as directives for how to build the unit test program. See: https://doc.rust-lang.org/cargo/reference/build-scripts.html Our `build.rs` file ignores the library path environment variables if thye're not set, which is necessary when building the libclamav_rust library and when libclamunrar isn't static and for when not linking with a libiconv external to libc. Rust test programs are built and executed in subdirectory under: <target>/<llvm triple>/<config>/deps where "target" for libclamav_rust tests is set to <build>/unit_tests For example: clamav/build/unit_tests/x86_64-pc-windows-msvc/debug/deps/clamav_rust-7e1343f8a2bff1cc.exe Since this program isn't co-located with the rest of the libraries we also have to set environment variables so the test program can find and load the shared libraries: - Windows: PATH - macOS: DYLD_LIBRARY_PATH We already set LD_LIBRARY_PATH when not Windows for similar reasons. Note: In build.rs, we iterate references to LIB_ENV_LINK & Co because older Rust versions do implement Iterator for [&str].
2021-11-18 10:24:00 -08:00
set(MY_CARGO_ARGS "test")
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
if(NOT "${CMAKE_OSX_ARCHITECTURES}" MATCHES "^(arm64;x86_64|x86_64;arm64)$") # Don't specify the target for universal, we'll do that manually for each build.
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
list(APPEND MY_CARGO_ARGS "--target" ${RUST_COMPILER_TARGET})
Add Rust logging module unit test & integrate with CMake / CTest Add a basic unit test for the new libclamav_rust `logging.rs` module. This test simply initializes logging and then prints out a message with each of the `log` macros. Also set the Rust edition to 2018 because the default is the 2015 edition in which using external crates is very clunky. For the Rust test support in CMake this commit adds support for cross-compiling the Rust tests. Rust tests must be built for the same LLVM triple (target platform) as the rest of the project. In particular this is needed to build both x64 and x86 packages on a 64bit Windows host. For Alpine, we observed that the LLVM triple for the host platform tools may be either: - x86_64-unknown-linux-musl, or - x86_64-alpine-linux-musl To support it either way, we look up the host triple with `rustc -vV` and use that if the musl libc exists. This is a big hacky and unfortunately means that we probably can't cross-compile to other platforms when running on a musl libc host. There are probably improvements to be made to improve cross compiling support. The Rust test programs must link with libclamav, libclammspack, and possibly libclamunrar_iface and libclamunrar plus all of the library dependencies for those libraries. To do this, we pass the path of each library in environment variables when building the libclamav_rust unit test program. Within `libclamav_rust/build.rs`, we read those environment variables. If set, we parse each into library path and name components to use as directives for how to build the unit test program. See: https://doc.rust-lang.org/cargo/reference/build-scripts.html Our `build.rs` file ignores the library path environment variables if thye're not set, which is necessary when building the libclamav_rust library and when libclamunrar isn't static and for when not linking with a libiconv external to libc. Rust test programs are built and executed in subdirectory under: <target>/<llvm triple>/<config>/deps where "target" for libclamav_rust tests is set to <build>/unit_tests For example: clamav/build/unit_tests/x86_64-pc-windows-msvc/debug/deps/clamav_rust-7e1343f8a2bff1cc.exe Since this program isn't co-located with the rest of the libraries we also have to set environment variables so the test program can find and load the shared libraries: - Windows: PATH - macOS: DYLD_LIBRARY_PATH We already set LD_LIBRARY_PATH when not Windows for similar reasons. Note: In build.rs, we iterate references to LIB_ENV_LINK & Co because older Rust versions do implement Iterator for [&str].
2021-11-18 10:24:00 -08:00
endif()
CMake+Rust: default build must be release with debug info We already set the default build type to RelWithDebInfo for CMake, but we were setting it *after* adding the Rust module. We need to do it before, or else the Rust stuff will still default to Debug, which makes for really slow scans of images that get fuzzy hashed.
2022-09-17 11:27:49 -07:00
if("${CMAKE_BUILD_TYPE}" STREQUAL "Release" OR "${CMAKE_BUILD_TYPE}" STREQUAL "RelWithDebInfo")
Add Rust logging module unit test & integrate with CMake / CTest Add a basic unit test for the new libclamav_rust `logging.rs` module. This test simply initializes logging and then prints out a message with each of the `log` macros. Also set the Rust edition to 2018 because the default is the 2015 edition in which using external crates is very clunky. For the Rust test support in CMake this commit adds support for cross-compiling the Rust tests. Rust tests must be built for the same LLVM triple (target platform) as the rest of the project. In particular this is needed to build both x64 and x86 packages on a 64bit Windows host. For Alpine, we observed that the LLVM triple for the host platform tools may be either: - x86_64-unknown-linux-musl, or - x86_64-alpine-linux-musl To support it either way, we look up the host triple with `rustc -vV` and use that if the musl libc exists. This is a big hacky and unfortunately means that we probably can't cross-compile to other platforms when running on a musl libc host. There are probably improvements to be made to improve cross compiling support. The Rust test programs must link with libclamav, libclammspack, and possibly libclamunrar_iface and libclamunrar plus all of the library dependencies for those libraries. To do this, we pass the path of each library in environment variables when building the libclamav_rust unit test program. Within `libclamav_rust/build.rs`, we read those environment variables. If set, we parse each into library path and name components to use as directives for how to build the unit test program. See: https://doc.rust-lang.org/cargo/reference/build-scripts.html Our `build.rs` file ignores the library path environment variables if thye're not set, which is necessary when building the libclamav_rust library and when libclamunrar isn't static and for when not linking with a libiconv external to libc. Rust test programs are built and executed in subdirectory under: <target>/<llvm triple>/<config>/deps where "target" for libclamav_rust tests is set to <build>/unit_tests For example: clamav/build/unit_tests/x86_64-pc-windows-msvc/debug/deps/clamav_rust-7e1343f8a2bff1cc.exe Since this program isn't co-located with the rest of the libraries we also have to set environment variables so the test program can find and load the shared libraries: - Windows: PATH - macOS: DYLD_LIBRARY_PATH We already set LD_LIBRARY_PATH when not Windows for similar reasons. Note: In build.rs, we iterate references to LIB_ENV_LINK & Co because older Rust versions do implement Iterator for [&str].
2021-11-18 10:24:00 -08:00
list(APPEND MY_CARGO_ARGS "--release")
endif()
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
list(APPEND MY_CARGO_ARGS "--target-dir" ${ARGS_BINARY_DIRECTORY})
Add Rust logging module unit test & integrate with CMake / CTest Add a basic unit test for the new libclamav_rust `logging.rs` module. This test simply initializes logging and then prints out a message with each of the `log` macros. Also set the Rust edition to 2018 because the default is the 2015 edition in which using external crates is very clunky. For the Rust test support in CMake this commit adds support for cross-compiling the Rust tests. Rust tests must be built for the same LLVM triple (target platform) as the rest of the project. In particular this is needed to build both x64 and x86 packages on a 64bit Windows host. For Alpine, we observed that the LLVM triple for the host platform tools may be either: - x86_64-unknown-linux-musl, or - x86_64-alpine-linux-musl To support it either way, we look up the host triple with `rustc -vV` and use that if the musl libc exists. This is a big hacky and unfortunately means that we probably can't cross-compile to other platforms when running on a musl libc host. There are probably improvements to be made to improve cross compiling support. The Rust test programs must link with libclamav, libclammspack, and possibly libclamunrar_iface and libclamunrar plus all of the library dependencies for those libraries. To do this, we pass the path of each library in environment variables when building the libclamav_rust unit test program. Within `libclamav_rust/build.rs`, we read those environment variables. If set, we parse each into library path and name components to use as directives for how to build the unit test program. See: https://doc.rust-lang.org/cargo/reference/build-scripts.html Our `build.rs` file ignores the library path environment variables if thye're not set, which is necessary when building the libclamav_rust library and when libclamunrar isn't static and for when not linking with a libiconv external to libc. Rust test programs are built and executed in subdirectory under: <target>/<llvm triple>/<config>/deps where "target" for libclamav_rust tests is set to <build>/unit_tests For example: clamav/build/unit_tests/x86_64-pc-windows-msvc/debug/deps/clamav_rust-7e1343f8a2bff1cc.exe Since this program isn't co-located with the rest of the libraries we also have to set environment variables so the test program can find and load the shared libraries: - Windows: PATH - macOS: DYLD_LIBRARY_PATH We already set LD_LIBRARY_PATH when not Windows for similar reasons. Note: In build.rs, we iterate references to LIB_ENV_LINK & Co because older Rust versions do implement Iterator for [&str].
2021-11-18 10:24:00 -08:00
list(JOIN MY_CARGO_ARGS " " MY_CARGO_ARGS_STRING)
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
if(ARGS_PRECOMPILE_TESTS)
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
list(APPEND ARGS_PRECOMPILE_ENVIRONMENT "CARGO_CMD=test" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}")
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
add_custom_target(${ARGS_NAME}_tests ALL
Cmake+Rust: Disable test precompile feature Precompiling the test executable causes `sudo make install` to fail. The issue is that because we don't know the OUTPUT file path for the test executable, CMake can't know if it doesn't need to rerun that command, so it will run it with any call to `make`. The problem is that cargo is will fail to run with `sudo` on many systems. This is generally okay, because we just fixed the issue where we had been compiling the dependencies for each module. Now that we only build the dependencies once, building the test executable is actually very fast. So compiling it during the test isn't so bad.
2022-09-15 08:30:44 -07:00
COMMAND ${CMAKE_COMMAND} -E env ${ARGS_PRECOMPILE_ENVIRONMENT} ${cargo_EXECUTABLE} ${MY_CARGO_ARGS} --color always --no-run
DEPENDS ${ARGS_PRECOMPILE_DEPENDS}
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
WORKING_DIRECTORY ${ARGS_SOURCE_DIRECTORY}
CMake, Rust: precompile test executable Precompile the test executable during the main build, after libclamav has built. This will make it so the compile time does not count against the test time. It also, unfortunately, make the main build take way longer. Removed 3 duplicate variables from the test ENVIRONMENT variable.
2022-09-06 09:18:44 -07:00
)
endif()
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
add_test(
Add Rust logging module unit test & integrate with CMake / CTest Add a basic unit test for the new libclamav_rust `logging.rs` module. This test simply initializes logging and then prints out a message with each of the `log` macros. Also set the Rust edition to 2018 because the default is the 2015 edition in which using external crates is very clunky. For the Rust test support in CMake this commit adds support for cross-compiling the Rust tests. Rust tests must be built for the same LLVM triple (target platform) as the rest of the project. In particular this is needed to build both x64 and x86 packages on a 64bit Windows host. For Alpine, we observed that the LLVM triple for the host platform tools may be either: - x86_64-unknown-linux-musl, or - x86_64-alpine-linux-musl To support it either way, we look up the host triple with `rustc -vV` and use that if the musl libc exists. This is a big hacky and unfortunately means that we probably can't cross-compile to other platforms when running on a musl libc host. There are probably improvements to be made to improve cross compiling support. The Rust test programs must link with libclamav, libclammspack, and possibly libclamunrar_iface and libclamunrar plus all of the library dependencies for those libraries. To do this, we pass the path of each library in environment variables when building the libclamav_rust unit test program. Within `libclamav_rust/build.rs`, we read those environment variables. If set, we parse each into library path and name components to use as directives for how to build the unit test program. See: https://doc.rust-lang.org/cargo/reference/build-scripts.html Our `build.rs` file ignores the library path environment variables if thye're not set, which is necessary when building the libclamav_rust library and when libclamunrar isn't static and for when not linking with a libiconv external to libc. Rust test programs are built and executed in subdirectory under: <target>/<llvm triple>/<config>/deps where "target" for libclamav_rust tests is set to <build>/unit_tests For example: clamav/build/unit_tests/x86_64-pc-windows-msvc/debug/deps/clamav_rust-7e1343f8a2bff1cc.exe Since this program isn't co-located with the rest of the libraries we also have to set environment variables so the test program can find and load the shared libraries: - Windows: PATH - macOS: DYLD_LIBRARY_PATH We already set LD_LIBRARY_PATH when not Windows for similar reasons. Note: In build.rs, we iterate references to LIB_ENV_LINK & Co because older Rust versions do implement Iterator for [&str].
2021-11-18 10:24:00 -08:00
NAME ${ARGS_NAME}
CMake+Rust: default build must be release with debug info We already set the default build type to RelWithDebInfo for CMake, but we were setting it *after* adding the Rust module. We need to do it before, or else the Rust stuff will still default to Debug, which makes for really slow scans of images that get fuzzy hashed.
2022-09-17 11:27:49 -07:00
COMMAND ${CMAKE_COMMAND} -E env "CARGO_CMD=test" "CARGO_TARGET_DIR=${ARGS_BINARY_DIRECTORY}" "RUSTFLAGS=${RUSTFLAGS}" ${cargo_EXECUTABLE} ${MY_CARGO_ARGS} --color always
CMake+Rust: Don't rebuild Rust dependencies Right now, each Rust-based target added in CMake is being built in its own directory under the build path. This causes Rust to build each module from scratch, meaning any dependencies they have in common are built twice. The solution in this commit is to specify the top level build directory as the target directory for every Rust build and test. Note this also changes where the `clamav_rust.h` file is generated. It is now also placed in the top-level build directory, instead of under the `build/libclamav_rust` directory. That's a bit of a side-effect, and could be rectified if needed, but it appears to have no ill-effects. It's the same location that we drop the clamav-types.h file, so I think it's fine, for now. Note that `clamav_rust.h` is not a public header, it's just so libclamav functions can call into libclamav_rust functions.
2022-09-07 13:44:03 -07:00
WORKING_DIRECTORY ${ARGS_SOURCE_DIRECTORY}
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
)
endfunction()
#
# Cargo is the primary tool for using the Rust Toolchain to to build static
# libs that can include other crate dependencies.
#
find_rust_program(cargo)
# These other programs may also be useful...
find_rust_program(rustc)
find_rust_program(rustup)
find_rust_program(rust-gdb)
find_rust_program(rust-lldb)
find_rust_program(rustdoc)
find_rust_program(rustfmt)
find_rust_program(bindgen)
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
if(RUSTC_MINIMUM_REQUIRED AND rustc_VERSION VERSION_LESS RUSTC_MINIMUM_REQUIRED)
message(FATAL_ERROR "Your Rust toolchain is to old to build this project:
${rustc_VERSION} < ${RUSTC_MINIMUM_REQUIRED}")
endif()
CMake-Rust [Windows]: Fix issue detecting native static libs Some change in Cargo/Rust version 1.70 or 1.71 appears to have broken the build on Windows because we are incorrectly attempting to check the native static libraries by compiling an empty file (/dev/null) which does not exist on Windows. A simple fix is to make an empty file of our own and use that instead. Fixes: https://github.com/Cisco-Talos/clamav/issues/990
2023-08-08 17:54:19 -07:00
if(WIN32)
file(TOUCH ${CMAKE_BINARY_DIR}/empty-file)
set(EMPTY_FILE "${CMAKE_BINARY_DIR}/empty-file")
else()
set(EMPTY_FILE "/dev/null")
endif()
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
# Determine the native libs required to link w/ rust static libs
CMake-Rust [Windows]: Fix issue detecting native static libs Some change in Cargo/Rust version 1.70 or 1.71 appears to have broken the build on Windows because we are incorrectly attempting to check the native static libraries by compiling an empty file (/dev/null) which does not exist on Windows. A simple fix is to make an empty file of our own and use that instead. Fixes: https://github.com/Cisco-Talos/clamav/issues/990
2023-08-08 17:54:19 -07:00
# message(STATUS "Detecting native static libs for rust: ${rustc_EXECUTABLE} --crate-type staticlib --print=native-static-libs ${EMPTY_FILE}")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
execute_process(
CMake-Rust [Windows]: Fix issue detecting native static libs Some change in Cargo/Rust version 1.70 or 1.71 appears to have broken the build on Windows because we are incorrectly attempting to check the native static libraries by compiling an empty file (/dev/null) which does not exist on Windows. A simple fix is to make an empty file of our own and use that instead. Fixes: https://github.com/Cisco-Talos/clamav/issues/990
2023-08-08 17:54:19 -07:00
COMMAND ${CMAKE_COMMAND} -E env "CARGO_TARGET_DIR=${CMAKE_BINARY_DIR}" ${rustc_EXECUTABLE} --crate-type staticlib --print=native-static-libs ${EMPTY_FILE}
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
OUTPUT_VARIABLE RUST_NATIVE_STATIC_LIBS_OUTPUT
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
ERROR_VARIABLE RUST_NATIVE_STATIC_LIBS_ERROR
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
RESULT_VARIABLE RUST_NATIVE_STATIC_LIBS_RESULT
)
string(REGEX REPLACE "\r?\n" ";" LINE_LIST "${RUST_NATIVE_STATIC_LIBS_ERROR}")
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
foreach(LINE ${LINE_LIST})
# do the match on each line
string(REGEX MATCH "native-static-libs: .*" LINE "${LINE}")
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
if(NOT LINE)
continue()
endif()
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
string(REPLACE "native-static-libs: " "" LINE "${LINE}")
string(REGEX REPLACE " " "" LINE "${LINE}")
string(REGEX REPLACE " " ";" LINE "${LINE}")
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
if(LINE)
message(STATUS "Rust's native static libs: ${LINE}")
set(RUST_NATIVE_STATIC_LIBS "${LINE}")
break()
endif()
endforeach()
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
if(NOT RUST_COMPILER_TARGET)
# Automatically determine the Rust Target Triple.
# Note: Users may override automatic target detection by specifying their own. Most likely needed for cross-compiling.
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
# For reference determining target platform: https://doc.rust-lang.org/nightly/rustc/platform-support.html
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
if(WIN32)
# For windows x86/x64, it's easy enough to guess the target.
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
set(RUST_COMPILER_TARGET "x86_64-pc-windows-msvc")
CMake: Improve Rust platform support Add support for Rust FreeBSD, OpenBSD targets Add support for Rust on GNU aarch64. Add support for Rust on Alpine (musl x86_64). Note: Current trick of checking for musl libc.so doesn't work when cross compiling. TODO: Find a better way to check if the target is MUSL. Add Rust toolchain to fix Dockerfile build.
2021-11-13 17:57:33 -08:00
else()
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
set(RUST_COMPILER_TARGET "i686-pc-windows-msvc")
CMake: Improve Rust platform support Add support for Rust FreeBSD, OpenBSD targets Add support for Rust on GNU aarch64. Add support for Rust on Alpine (musl x86_64). Note: Current trick of checking for musl libc.so doesn't work when cross compiling. TODO: Find a better way to check if the target is MUSL. Add Rust toolchain to fix Dockerfile build.
2021-11-13 17:57:33 -08:00
endif()
CMake: arch order fix for Rust-based OSX universal binaries The FindRust.cmake module is hard-coded to expect CMAKE_OSX_ARCHITECTURES value of "arm64,x86_64" to build a Rust-based Apple universal binary. If the build uses "x86_64,arm64", which is equivalent, then the build will fail. Order should not matter.
2022-07-11 18:16:45 -06:00
elseif(CMAKE_SYSTEM_NAME STREQUAL Darwin AND "${CMAKE_OSX_ARCHITECTURES}" MATCHES "^(arm64;x86_64|x86_64;arm64)$")
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
# Special case for Darwin because we may want to build universal binaries.
set(RUST_COMPILER_TARGET "universal-apple-darwin")
CMake: Improve Rust platform support Add support for Rust FreeBSD, OpenBSD targets Add support for Rust on GNU aarch64. Add support for Rust on Alpine (musl x86_64). Note: Current trick of checking for musl libc.so doesn't work when cross compiling. TODO: Find a better way to check if the target is MUSL. Add Rust toolchain to fix Dockerfile build.
2021-11-13 17:57:33 -08:00
else()
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
# Determine default LLVM target triple.
execute_process(COMMAND ${rustc_EXECUTABLE} -vV
OUTPUT_VARIABLE RUSTC_VV_OUT ERROR_QUIET)
string(REGEX REPLACE "^.*host: ([a-zA-Z0-9_\\-]+).*" "\\1" DEFAULT_RUST_COMPILER_TARGET1 "${RUSTC_VV_OUT}")
string(STRIP ${DEFAULT_RUST_COMPILER_TARGET1} DEFAULT_RUST_COMPILER_TARGET)
CMake: Improve Rust platform support Add support for Rust FreeBSD, OpenBSD targets Add support for Rust on GNU aarch64. Add support for Rust on Alpine (musl x86_64). Note: Current trick of checking for musl libc.so doesn't work when cross compiling. TODO: Find a better way to check if the target is MUSL. Add Rust toolchain to fix Dockerfile build.
2021-11-13 17:57:33 -08:00
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
set(RUST_COMPILER_TARGET "${DEFAULT_RUST_COMPILER_TARGET}")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
endif()
endif()
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
set(CARGO_ARGS "build")
Auto-format CMakeRust module with vscode
2022-09-04 12:00:31 -07:00
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
if(NOT "${RUST_COMPILER_TARGET}" MATCHES "^universal-apple-darwin$")
CMake, Rust: Improve toolchain (target triple) selection The current method of trying to determine the target triple based the architecture, operating system, etc. is difficult to get right and maintain. In particular, I found that some installations like the Alpine package will use "alpine" in the name of the triple instead of "unknown". E.g. "aarch64-alpine-linux-musl" instead of "aarch64-unknown-linux-musl". This makes it nearly impossible to figure out the exact target name based on target system specifications. I believe it will be better to use the default target 99% of the time and require users that which to cross-compile to use a new CMake variable `-D RUST_TARGET_TRIPLE=<target>` to choose the target. This is basically how it works for C/C++ anyways.
2022-02-23 19:49:44 -08:00
# Don't specify the target for macOS universal builds, we'll do that manually for each build.
list(APPEND CARGO_ARGS "--target" ${RUST_COMPILER_TARGET})
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
endif()
if(NOT CMAKE_BUILD_TYPE)
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
set(CARGO_BUILD_TYPE "debug")
CMake: Rust RelWithDebInfo and MinSizeRel builds RelWithDebInfo is our preferred build type. It has optimizations and should run faster, but includes debugging symbols for better profiling, stack traces, etc. The Rust MinSizeRel support is just Release mode for now. There are optimizations we can do to shrink it further, but for now at least it won't actually be Debug (aka slow).
2021-11-23 19:35:35 -08:00
elseif(${CMAKE_BUILD_TYPE} STREQUAL "Release" OR ${CMAKE_BUILD_TYPE} STREQUAL "MinSizeRel")
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
set(CARGO_BUILD_TYPE "release")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
list(APPEND CARGO_ARGS "--release")
CMake: Rust RelWithDebInfo and MinSizeRel builds RelWithDebInfo is our preferred build type. It has optimizations and should run faster, but includes debugging symbols for better profiling, stack traces, etc. The Rust MinSizeRel support is just Release mode for now. There are optimizations we can do to shrink it further, but for now at least it won't actually be Debug (aka slow).
2021-11-23 19:35:35 -08:00
elseif(${CMAKE_BUILD_TYPE} STREQUAL "RelWithDebInfo")
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
set(CARGO_BUILD_TYPE "release")
CMake: Rust RelWithDebInfo and MinSizeRel builds RelWithDebInfo is our preferred build type. It has optimizations and should run faster, but includes debugging symbols for better profiling, stack traces, etc. The Rust MinSizeRel support is just Release mode for now. There are optimizations we can do to shrink it further, but for now at least it won't actually be Debug (aka slow).
2021-11-23 19:35:35 -08:00
list(APPEND CARGO_ARGS "--release")
CMake: Allow passing in custom RUSTFLAGS A user building clamav may now set the RUSTFLAGS CMake variable if additional options such as `--verbose` are desired. E.g. cmake .. -D RUSTFLAGS="--verbose" See `rustc --help` for more details.
2023-03-22 16:39:04 -06:00
string(APPEND RUSTFLAGS " -g")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
else()
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
set(CARGO_BUILD_TYPE "debug")
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
endif()
CMake: Allow passing in custom RUSTFLAGS A user building clamav may now set the RUSTFLAGS CMake variable if additional options such as `--verbose` are desired. E.g. cmake .. -D RUSTFLAGS="--verbose" See `rustc --help` for more details.
2023-03-22 16:39:04 -06:00
string(STRIP "${RUSTFLAGS}" RUSTFLAGS)
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
CMake, Rust: Add support for building Rust executables Update CMakeRust.cmake from github.com/micahsnyder/cmake-rust-demo Add the ability to build Rust-based executables from CMake.
2022-09-04 11:39:38 -07:00
find_package_handle_standard_args(Rust
CMake: Add Rust toolchain detection
2021-03-04 21:14:08 -08:00
REQUIRED_VARS cargo_EXECUTABLE
VERSION_VAR cargo_VERSION
)
Reference in a new issue Copy permalink