dascandy
commented
4 years ago That's pretty much what we had, until somebody decided to add a CMakeLists.txt doing just this. The bootstrap is getting it compiled once, and then compiling it again using itself which also runs all the unit tests. I believe the makefile is still set up such.
Anyway, in order to get people bootstrapped more quickly, I'm working on Azure Pipelines support that should output the Evoke binaries for people to use. See also the badge near the top I added a few hours ago.
I'm also working on a more thorough fix for the dependencies problem. Will take more time though.
Describe the bug CMake is unable to find Boost.
To Reproduce Steps to reproduce the behavior:
Expected behavior Boost is found by CMake.
Screenshots
System (please complete the following information):
Additional context So CMake and Boost have a "funny" history in that CMake has hard-coded Boost layout and every time Boost makes a release it breaks CMakeList.txt that relies on in-built support of Boost in CMake. It takes CMake people LONG time to fix this every time. Today it is almost 3 monts since last Boost release (28th August) and almost 2 from last CMake release (2nd October).
Anyhow, this is really inpractical and I would suggest ditching reliance on CMake and Boost magically being available & compatible versions. Instead create a git subtree in Evoke repo pointing here: https://github.com/boostorg/filesystem and here: https://github.com/boostorg/system
And point CMake to those places directtly bypassing this unreliable Boost detection. You will also gain control over what version of Boost you and users of Evoke are using AND drop the only external dependency you have (except for CMake itself). Arguably CMake could be ditched as well. Judging from contents of the CMakeLists.txt a batch/sh file to bootstrap Evoke would be pretty trivial.