Oct 24, 2018

An artifact of the xml as in autotools they are applied to both c and c++. Cmake doesn't carry that distinction as I could identify. It also results in a few warnings when noreorder isn't applicable to c.

Not entirely sure what you mean though, in CMake you only have to mention them once afaik. Also, they use the global add_compiler_flag but the recommended way, I believe, is to use target-specific methods e.g target_add_compiler_flag. Is there a reason for using the other setup?

The cmake artifact is generated from our libbitcoin-build project which generates from common information currently placed in a file generate.xml. I agree that duplicate declaration is not necessary, however it wasn't harmful and to avoid it would require detecting the redundancy in the generate.xml and excluding it. Given the intent for all such flags to apply to all targets, add_compiler_flag is the proper mode of declaration.

is the compiler_flag method what you're referring to when you say setup or are you pointing to something else?

Aah, that explains it, ok interesting method of creating CMake recipes 🙂

yes that's what I meant. I should note though that using global flags can mess with situations where the library is used as a dependency, which can create complicated hard-to-debug builds

I'll try to integrate the new CMake build with Conan and see if I hit any issues, could be the builds are isolated well enough that it doesn't matter 🙂

I don't see how that could be the case. If you're linking the library as a dependency, you needn't rely on the CMakeList.txt. Cmake can invoke pkg-config - it's what I'm doing in FindLibbitcoin.cmake

someone could try to use libbitcoin with External_Project_Add from CMake, which would lead to the issue I mentioned

it also retains the pkg-config/pc file mechanism that is used in the autotools build. they generate identical .pc files and will link between build systems

not a recommended approach. The global flag approach excludes some uses of the library in certain build set-ups, which is why I mentioned it

It may also lead to issues for people building libbitcoin using add_subdirectory and just copying the library to their local set-up

certainly, however I thought was ill-advised and why Find<foo>.cmake mechanisms exist. While i don't install a copy of them with the installed library, I believed that was the desired mechanism for inclusion

certainly, that is the recommended way indeed, and I would say nowadays it's probably best to use Conan or another package manager. The main point being, you don't have control over or know exactly where your library will be used and how it will be built, using the globals means some techniques won't work, but that will be detected most likely through odd build failures

I'd assume that all non-target mechanisms would potentially cause problems, which would require a tradeoff between include directory inclusion at the target and the suppression of warnings due to SYSTEM declared directories.

I.e. unless you provide a very clear documentation stating exactly what your build set-up requires (e.g. examples of how to include libbitcoin in a CMake build) you may get some odd issues regarding build failures.

by issues I mean, users making Github issues about failed builds btw

I'll get a conan example up and running, which is what I would recommend as library vendor to my users 🙂

i'll look forward to it. easy enough to point to any but the base library's mechanism for including other repository libraries.

I've got it working locally with the autotools set-up 😄

were you encountering problems with autotools?

my testing conanfile:

[requires]
libbitcoin-node/0.1.0@blockport/stable
fmt/5.1.0@bincrafters/stable
spdlog/1.1.0@bincrafters/stable
range-v3/0.3.7@blockport/stable
dry_comparisons/0.1.0@blockport/stable
tl_expected/0.2.1@blockport/stable

[generators]
cmake

[imports]
lib, *.so* -> ./lib
lib, *.a -> ./lib

It took a moment to get all dependencies found correctly when using autotools and conan together, but the pkg-config being available allowed conan to reuse that 🙂

i'm not aware of conan, so i'm not clear what i'm looking at. i assume it's a package distribution system

package /dependency management for C++ (but generic enough to be used for other languages too)

see conan.io

It means a libbitcoin based project to build a custom node, would only need that line in a file called conanfile.txt and then it would pull it in and build/link everything correctly 🙂

Coming from a project where I had to manage all deps using CMake, switching to Conan has made my life much nicer 😄

well, if you can get it working, that'll be great. if it's generalizable then we might be able to pull together a gsl generator to maintain it.

it works already so far 🙂

would need some validation though

and I need to find out from my employer if I can publish this as is, given I've made this at work

i'm not sure what the requires section contains. are those supposed to be version numbers?

Yeah, the syntax is not very clear there. Those are package version numbers. I picked 0.1.0 for the time being, but that should be the semver of libbitcoin when used officially

probably 3.X.X in this case

It's essentially: name/version@repository/channel

if you're using master, it's currently 4.x.x in anticipation. but it doesn't take much other than cherry picking to backport the generator to 3

I'm using version3 as I am actually building on top of libbitcoin myself and need a stable version 🙂

though I am eagerly awaiting v4 😄

is this the conanfile for your own project? we don't bring in those dependencies

that's my project yes

requires packages for all dependencies. but if you've got it working they mostly must already exist

the dependencies for libbitcoin mostly exist as conan packages

anyway, if you happen to encounter any cmake failures due to environment or system changes, i'd be interested. don't have access to osx, don't know if it'll work. will be testing with travis in a bit, once i rework our installer script

i'm off to bed

👍

👋