CMake Version Conflict Between Package and libquickfix Submodule

[Soroushsrd]

When attempting to build the quickfix-ffi crate on Arch Linux using cargo check, I encountered a build failure with the following error:

cargo check
warning: unused manifest key: target.x86_64-pc-windows-gnu.linker
warning: unused manifest key: target.x86_64-pc-windows-gnu.rustflags
   Compiling quickfix-ffi v0.1.6
error: failed to run custom build command for `quickfix-ffi v0.1.6`
Caused by:
  process didn't exit successfully: `***/target/debug/build/quickfix-ffi-08f6c8d4e992209f/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=./CMakeLists.txt
  cargo:rerun-if-changed=./libquickfix
  cargo:rerun-if-changed=./quickfix-bind
  CMAKE_TOOLCHAIN_FILE_x86_64-unknown-linux-gnu = None
  CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_x86_64-unknown-linux-gnu = None
  CMAKE_GENERATOR_x86_64_unknown_linux_gnu = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_x86_64-unknown-linux-gnu = None
  CMAKE_PREFIX_PATH_x86_64_unknown_linux_gnu = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_x86_64-unknown-linux-gnu = None
  CMAKE_x86_64_unknown_linux_gnu = None
  HOST_CMAKE = None
  CMAKE = None
  running: cd "***target/debug/build/quickfix-ffi-acfbf5cc0a300cc2/out/build" && CMAKE_PREFIX_PATH="" "cmake" "***/target/debug/build/quickfix-ffi-acfbf5cc0a300cc2/out/libquickfix" "-DHAVE_SSL=OFF" "-DHAVE_MYSQL=OFF" "-DHAVE_POSTGRESQL=OFF" "-DHAVE_PYTHON=OFF" "-DHAVE_PYTHON3=OFF" "-DQUICKFIX_SHARED_LIBS=OFF" "-DQUICKFIX_EXAMPLES=OFF" "-DQUICKFIX_TESTS=OFF" "-DCMAKE_INSTALL_PREFIX=***/target/debug/build/quickfix-ffi-acfbf5cc0a300cc2/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=RelWithDebInfo"
  -- Configuring incomplete, errors occurred!
  --- stderr
  CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
    Compatibility with CMake < 3.5 has been removed from CMake.
    Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
    to tell CMake that the project requires at least <min> but has been updated
    to work with policies introduced by <max> or earlier.
    Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.
  thread 'main' panicked at ***/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cmake-0.1.54/src/lib.rs:1119:5:
  command did not execute successfully, got: exit status: 1
  build script failed, must exit now
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Environment

Operating System: Arch Linux
Rust Version: 1.86
CMake Version: 4.0.1
quickfix-ffi Version: 0.1.6

The issue seems to be regarding

cmake_minimum_required(VERSION 3.0 FATAL_ERROR)

in libquickfix/CmakeLists.txt

[arthurlm]

This should now be fixed 😄!

Please note that the issue comes from original QuickFix C++ library.
I did a "workaround" to make it works but that's definitely not ideal.
I think it should be nice if you can raise the issue also to the C++ library.

[Soroushsrd]

Thank you for the fix. yeah it was due to Quickfix.
I was wondering if it would be worth while to remove this dependency on Quickfix ffi and rewrite it in rust?

[arthurlm]

Not sure to fully understand your question 😅.

Actually the purpose of quickfix-ffi is to provide a binding to QuickFix C++ library.
See: DEV NOTES

QuickFix C++ is the actual FIX engine and it is huge !
I have strip it to the bare minimum with few patches in the official library + some compilation option in build.rs script + some cleanup when packaging the quickfix-ffi library.
However, below is the amount of code still necessary at bare minimum to have a full FIX engine working:

❯ tokei target/package/quickfix-ffi-0.1.6/libquickfix 
===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 Autoconf                1           10            0            8            2
 Automake                1          199          187            0           12
 C                       1          296          191           69           36
 C Header              106        35015        28596         4026         2393
 CMake                   9          833          600          148           85
 C++                    62        34216        26770         3314         4132
 C++ Header              3         1808          959          452          397
 Shell                   1           24           12            9            3
===============================================================================
 Total                 184        72401        57315         8026         7060
===============================================================================

Re-implementing it in pure rust would be a massive challenge 😅!

[Soroushsrd]

Thats exactly what i meant. rewriting the whole thing in rust could have its benefits. I mean i have been using your crate in production setting and although it's perfect (thank you for that), i had to play around the ffi bindings and types to make it work (although it can be "skill issues" on my part).

[arthurlm]

I agree that rewriting the full QuickFIX library in Rust would definitely have its advantage. But it is really a massive challenge, and I do not have the time and energy to do it 😅.
Also keep in mind that QuickFIX C++ is the industry standard (it is used in few major European bank I have work with) and maintain by Oren Miller since more than 20+ years!

I give a try rewriting my engine from scratch before.
But it was definitely too advanced for me.

---

To give you the full story of why I end up writing this library:

Few years ago, when I was working for a portfolio manager in an hedge fund, we need a FIX implementation in Rust to communicate with brokers.
I check what was available in the Rust ecosystem, but nothing was really shinning.
There was the FerrumFIX crate there, but it did not looks as "production ready" as QuickFIX was.
We were massively using QuickFIX C++ internally, so the most logical option was to continue using it ... but in Rust.
That's why I end up writing this tiny wrapper above it and in few days it was up and running.

I end up reaching Oren Miller to get is approval for making it "official".
He agree and here we are 😁!

With Oren Miller we discuss about:

• Making the Rust crate API as close as possible from original C++ implementation.
• Hiding as much as possible from C++ library (ideally you would not notice there is C++ in the stack).
• Having most features available from Rust crate (if something is missing feel free to open new issue).

Currently C++ is still in charge of:

• Socket + session management
• Message validation + decoding + encoding + checksum validation + checksum computation
• Handling SeqNum + replay + duplication message check
• Login / logout
• Resetting session when something is not working as expected
• Extra features (like the HTTP Server to control at runtime session management)

Finding the balance between Rust / C++ role is something really challenging 😀!

[Soroushsrd]

wow that's an interesting story :D. Would it be ok if i start writing the parts we talked about in rust? I know its gonna take a long time but sounds like a nice long term projects which should improve my skills as well. Maybe then we could merge the two projects and have a 100% rust based QuickFix protocol :))

[arthurlm]

Sure! Feel free to fork the repo and do your changes 😄.
You can still open a PR and mark it as WIP / Draft so I can follow the change and give hint if needed.

What I suggest is creating a new crate in that repo like quickfix-native (or something like this) that can replace progressively quickfix-ffi in quickfix crate.

So the oxidation (aka: conversion into Rust 😉) would be transparent for end-users of the library.

[Soroushsrd]

Thank you! Will get right on it 😃