Convert project build process to cmake

[ngie-eign]

In order to build this project on many operating systems (including FreeBSD, macOS with Homebrew, etc), one generally needs to reinvent the wheel in order to build the project on their target OS of choice due to issues with compilers, package pathing, etc.

This change incorporates a lot of the already invented wheels from the cmake project around OpenMP and pkg-config so the information previously hardcoded is now obtained via maintainer provided pkg-config files.

This change also makes it possible to redistribute binaries for the project and generate SBOMs for the contents in the project more easily.

Some effort is required to get this project to build with FreeBSD (see this Phabricator review for more details: https://reviews.freebsd.org/D56885).

Update .gitignore per the changes.

Tested on: FreeBSD 14.4, macOS 26.3.1
Signed-off-by: Enji Cooper yaneurabeya@gmail.com

[celic]

Thanks for the contribution. Cross-platform compilation has always been tough for this project. I'm not as familiar with cmake. However we do have internal dependencies that rely on this makefile. Is it possible for both cmake and make to exist here?

[ngie-eign]

Thanks for the contribution.

Of course — thank you too.

Cross-platform compilation has always been tough for this project. I'm not as familiar with cmake. However we do have internal dependencies that rely on this makefile. Is it possible for both cmake and make to exist here?

Hm. Could you please better describe the “internal dependencies”? The overarching goal of cmake is to produce portable makefiles. All that you should need to do is call cmake once, then call make as you would before (albeit with different arguments). Most of the prior calls have parallels after this change, but if you need more details, please let me know!

[celic]

We have a very simple build chain internally for ESVTS to run the C++ within a Docker container. Our containers use the makefile to build. This would need to be updated and tested in tandem.

As well I know of downstream users such as https://github.com/smuellerDD/jitterentropy-library/tree/master/tests/raw-entropy/validation-runtime. Getting verification from the author that removing the makefile does not disrupt their build processes would be helpful.

We have had it on the todo list for too long to enable this library on more platforms, so I am very interested in merging this in once I can test it locally. I've got an Ubuntu VM and native MacOS to try this out on. Do you have any experience running this on something like Windows Subsystem for Linux (WSL)?

[ngie-eign]

We have a very simple build chain internally for ESVTS to run the C++ within a Docker container. Our containers use the makefile to build. This would need to be updated and tested in tandem.

As well I know of downstream users such as https://github.com/smuellerDD/jitterentropy-library/tree/master/tests/raw-entropy/validation-runtime. Getting verification from the author that removing the makefile does not disrupt their build processes would be helpful.

Ironically, if integration is done at the cmake level, this change would make it easier to vendor the project in downstream projects (FetchContent, etc) (CC: @smuellerDD).

We have had it on the todo list for too long to enable this library on more platforms, so I am very interested in merging this in once I can test it locally. I've got an Ubuntu VM and native MacOS to try this out on. Do you have any experience running this on something like Windows Subsystem for Linux (WSL)?

I just ran the build in an Ubuntu 25.04 (Plucky) WSL2 container. I haven't verified that the content works beyond just doing a basic smoke test (getting the usage message for various utilities) on 25.04, but it definitely builds using the instructions in README.md .