Closed hugolm84 closed 3 years ago
@hugolm84 Since fsmlite
is a pure header library, the autotools
support is basically there for supporting unit tests. Since I'm much more familiar with autotools
than CMake
, I'll probably continue to make it the default. Especially since support for embedded platforms (my major concern) and cross-compiling is or has been an issue with CMake
, but is said to have been improved with "modern" CMake
(3.1+), and I'm always curious to learn some new tricks ;-)
However, a PR supporting CMake would be more than welcome! If you're not trying to replace autotools
but make this optional, doubly so ;-)
Instructions for the uninitiated (e.g. cross-compiling for ARM targets) would definitely be a bonus, but that's up to you...
Hi @tkem
Support for embedded platforms and cross compilation should not be an issue using CMake at this time. I am using Modern CMake and support multiple platforms, some more esoteric than others, using the CMake as build configuration tool.
I could do a CMake PR that could work side by side with your autotools and Makefiles. The main objective for me is to let CMake find fsmlite
using find_package
and allow for linking in existing CMake projects.
Instructions for example ARM should not be an issue 👍
Hi, thanks for all the work on this project!
I'm building and using fsmlite via CMake. This way I am able to find, link and test fsmlite on multiple platforms. I was wondering if a PR for support of CMake would be considered? Perhaps even replacing Make.
That way you could easily build and test using MSVC, GCC, Clang or any other compiler. To be able to build the tests with MSVC >=19.14, a change was required for successful compilation, basically:
After that, testing is easy as
ctest -C Debug