Add cmake build system #290
No reviewers
Labels
No labels
area: devops
area: discovery
area: docs
area: livestream
area: proposal
consider soon
Epic
good first issue
hacktoberfest
hard fork
help wanted
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
on hold
priority: blocker
priority: high
priority: low
priority: medium
resilience
soft fork
Tom's Wishlist
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
work in progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbrycrd#290
Loading…
Reference in a new issue
No description provided.
Delete branch "cmake_build"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Signed-off-by: Anthony Fieroni bvbfan@abv.bg
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.
I did some testing on this today. Here are issues that I see with it:
The boost build doesn't correctly locate the ICU libs. This is a must-have. "Performing configuration checks" must report that it found the ICU. I played with this for a little while in trying to make it more like the boost.mk that we use presently. However, I was unable to make it work.
Do we really need a separate b2 call for headers?
The Boost and ICU and other builds don't account for the RELEASE vs DEBUG build flags in CMake.
Use Boost 1.69 and ICU 63.2.
It was unable to locate my local boost libraries.
If use a local boost library, we don't need to use ICU.
We don't need program_options boost component, and the test component is named "test".
I think lbrycrd's --enable-cxx is deprecated.
It would be nice to use cmake vars instead of using "x86_64", etc. directly.
Yes.
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).
Component is called unit_test_framework, i used in local build too.
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.
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.
Would it be better to default this to ON? I kind of like the idea of using local dependencies by default.
What exactly fails?
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.
The "depends" system uses
sedinstead ofpatchto achieve this. It doesn't need the extra file. Thesedapproach seems superior to me.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.
I just test with KDevelop, it works, open project, import CMakeFiles.txt and then run build.
Boost version should be increase as well, not tag only.
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.