Add cmake build system

[bvbfan]

Signed-off-by: Anthony Fieroni bvbfan@abv.bg

[bvbfan]

We can use cmake as reproducible build system, as well as rolling one. By default it's done to perform a monolith (static) build of all depends, on other hand it can be used to perform dynamic build against system libraries. The flexibility is that when depend is not found in system libs it's compiled as static one, so we have exactly what you need. On the other hand i have an idea to manage a branch that includes diffs by file against concrete bitcoin version so you can reproduce exactly the version you want. Since that is not very interesting in previous version, it'll be pretty much to newer one, since you can easy try to apply all patches on top of newer bitcoin version to generate a lbrycrd one. When can tag changes in diffs like tags in bitcoin which will make process easier, despite that menage and review diffs is not that easy task, it should be done by manually testing but furthermore i think this will make future rebases painless.

[bvbfan]

Do we really need a separate b2 call for headers?

Yes.

If use a local boost library, we don't need to use ICU.

I don't get it. We need ICU when we build boost locally, we don't need if we use system wide one (because it's prebuild with icu in).

and the test component is named "test"

Component is called unit_test_framework, i used in local build too.

It would be nice to use cmake vars instead of using "x86_64", etc. directly.

Good catch, i'll correct it.

Can you show the output, i've test it in all variants, boost locate icu in my test cases.

[BrannonKing]

I tested this with Clion today. It doesn't work. However, I have found a new and better way to make Clion work with the autotools stuff. Essentially, you use compiledb to build the compile_commands.json file from the make file. This works better than that older CMakeLists.txt file I've been using. With that in mind, I'm thinking to get rid of the CMakeLists.txt file. This newer CMake approach allows a mix of local and downloaded dependencies. That is an improvement over the existing build system, where it's either all or nothing on local dependencies (or it's some custom build work). At the same time, I don't want to confuse our users by having multiple ways to build the project. Another advantage of CMake is that it keeps the compiled files separated from the sources. However, the present approach to using Externals doesn't quite achieve this goal.

[bvbfan]

What exactly fails?

[BrannonKing]

Clion must be using the files passed to the add_executable/library Cmake commands. Those aren't called as part of the ExternalProject stuff. Like I said, though, this other approach with compiledb actually works much better than what I had.

[bvbfan]

Clion, or any other IDE, should call cmake 'dir' then make, it shouldn't care it's external project or not. IMHO you can add custom command at end to satisfy Clion needs.

[bvbfan]

I just test with KDevelop, it works, open project, import CMakeFiles.txt and then run build.

[BrannonKing]

No, I did the version number very specifically: I want to download the 69 if I'm going to download one. If I'm not going to download one, then version 64+ will be fine.