Add CMake build files #2
Conversation
The SSE compiler feature detection was always flaky and would need to be maintained in spite of the fact that it doesn't add much value as the compilation would just fail if the user incorrectly assumes that his compiler supports the required instruction sets. - Enable cmake test support.
|
I definitely appreciate the CMake addition, but this brings also a few other additions that are ABI-breaking. This is basically the suggestion over at BLAKE2/BLAKE2#40 that I agree with, but have been putting off precisely because of it potentially breaking things. So, this would definitely need to also bump the .so version up in the autoconf and CMake configuration files. |
|
@sneves oh, I'm deeply sorry; I made those changes for internal usage and hadn't had this pull request in mind when I pushed them. How do you want to proceed? |
|
Was any decision made here? Maybe cut this PR down to just the build system stuff with no internal changes? |
|
Also, I don't understand the comment on the "Remove SSE compiler feature detection" commit. Why was it flaky? Does removing it mean that compilation will fail on platforms that don't have those x86 extensions? |
Well, it hasn't been merged since 2015 and extrapolating from that I don't think it'll happen until a maintainer needs it.
The approach I've taken back then was to grep the sources for intrinsics and add compile tests with these intrinsics. Obviously this has to be kept in sync manually which I consider an unnecessary burden (usually either all or none of those sse intrinsics are supported by compilers/instruction set). Instead I just offer an option to completely exclude the dispatch logic and SSE code. |
|
Please continue using libtool, because CMake does not support, or is broken on some target platforms where libtool does work - namely AIX for example. |
|
Can I kindly bump up this PR again? Its really challenging to build libb2 anywhere outside of GNU/Linux. cmake is widely used in the C/C++ world, and I think it would make it easier for people to adopt blake2. |
|
I can't speak for Samuel and the others, but adding CMake to The minimum requirements of CMake 3.0 is too high. The CMake build will fail on a lot of platforms, including Ubuntu LTS releases, AIX, some BSDs, Solaris, and OS X. That's just going to create bug reports. It would probably be better to drop the minimum to CMake 2.8. OpenMP support has a lot of gaps. Here's a more complete list of OpenMP options from different compilers: ax_openmp.m4. That file actually has a bug - SunCC needs The reason to classify CMake as unsupported... What I found in other projects is, the CMake fans rush in and ask for CMake. After it is added, the fans leave and the bugs must be worked by the project maintainers. CMake accounted for 28% of our bugs so we eventually dropped CMake support. It had too many problems and was taking up too much of our time. |
I'm not sure whether this is really a problem, especially if you say that CMake should be "officially unsupported". Also, the oldest release of Ubuntu that has still standard LTS support is 16.04 which has cmake 3.5. Only 14.04 with its extended security support still uses cmake 2.8. |
I politely disagree; on the contrary I recommend requiring at least CMake 3.1 which introduced That said, I also can't think of a system which could neither use autotools nor cmake 3.1, but would be able to use cmake 2.8. |
|
hello, could you rebase on current master ? |
|
Thanks for the nice work! Could this be reconsidered? |
I ported my CMake build scripts from BurningEnlightenment/libb2-cmake.
It supports building the library with all code paths or with reference sources only with MSVC, MinGW and Clang (tested only on Windows), although it currently lacks OpenMP support on Clang. Furthermore it can build the test drivers.
However, the main feature is the install target which allows the library to be used from other CMake projects (especially on Windows) very easily.