mbsim-env / fmatvec

A fast vector/matrix library
https://www.mbsim-env.de
GNU Lesser General Public License v2.1
10 stars 5 forks source link

cmake build gcc #4

Closed GreenGary closed 2 years ago

GreenGary commented 4 years ago

I have seen the cmake branch here, which started in 2015 and which is based on cmake 2.x (as far as I have seen). With this issue, I want to push for a sound, maintained cmake build.

I would like to see (and implement) the following:

Remarks:

friedrichatgc commented 4 years ago

The current cmake branch is fully outdated. We may tag the current cmake branch and then reuse this branch name.

I would also propose cmake >=3. The docker files for the build system already use cmake3 to build some dependencies. In centos7 just install "yum install epel-release" then "yum install cmake3" and than just use "cmake3" being version 3.14.7.

For the transition phase to cmake it would be great when cmake and autotools can be used alternatively in the cmake branch. This way we can still check the cmake branch using the CI on www.mbsim-env.de without adaptions on the CI. If finished we may switch the CI to use the cmake build. config.h should be replaced, if possible, even for the autotools build.

Ninja as the only generator for cmake would also be fine for me.

rolandzander commented 4 years ago

As communicated, the current cmake branch is not fully outdated (any more) since commit https://github.com/mbsim-env/fmatvec/commit/ed36a00b805390de18dc26bf68bae3732b8447b8#diff-af3b638bc2a3e6c650974192a53c7291 Tag should be added to the commit right before.

The cmake branch provides a cmake based build being functional on current Debian/Ubuntu systems and at least needs addition of the MSVC part. By now, ninja is not tested by my. The build provides both cmake as well as pkgconfig package information for interfacing with the build result.

By now, the branch should provide a good starting point for the proposed developments but needs clean-ups.