--- Log opened Tue Jun 07 00:00:45 2022 01:02 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-builds 01:48 -!- z9z0b3t1c [~z9z0b3t1c@145.224.66.152] has quit [] 06:09 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds] 06:27 -!- kinlo [~peter@user/kinlo] has joined #bitcoin-core-builds 06:31 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-builds 06:32 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-builds 06:44 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-builds 06:49 < theStack> hebasto: tried your cmake branch cmake/0607 on OpenBSD 7.1, currently it fails building libsecp256k1 (https://pastebin.com/GUzfNM25) 06:50 < theStack> seems to be something trivial though (missing -I parameter?) 06:50 < hebasto> theStack: thanks for testing; this bug has been already squashed (thanks to vasild ) 06:51 < theStack> oh and i had to remove "COMPONENTS headers" from the "find_package(Boost..." line, like vasild did for FreeBSD 06:51 < hebasto> a fixed tag will be pushed soon 06:51 < theStack> hebasto: ah nice, good to hear :) 06:56 < vasild> "error: '../include/secp256k1.h' file not found" -- how was this fixed? 07:03 < hebasto> oh, misread; sorry 07:21 < hebasto> CMake migration update -- https://gist.github.com/hebasto/aac97d2f6b18c4ec2ad951baeb1ac00c; fixed builds on FreeBSD, added an example for FreeBSD 07:28 < laanwj> hebasto: will re-test 07:28 < hebasto> laanwj: thanks! 07:29 < laanwj> TIL about `cmake --build` 07:29 < sipa> TIL as well 07:30 < theStack> laanwj: heh, same here. i always used to do something like "mkdir build && cd build && cmake .. && make" 07:31 < laanwj> theStack: same! i guess that's equivalent unless the inner build system isn't (g)make, after all, cmake also supports eg. ninja and MSVC 07:34 < vasild> TIL too :-D 07:35 < vasild> I like "cmake --build" because it abstracts the details of which underlying build system is used 07:37 < vasild> hebasto: given that the point of cmake is to be OS agnostic, maybe in https://gist.github.com/hebasto/aac97d2f6b18c4ec2ad951baeb1ac00c there is no need to give per-OS instructions (except cross-compiling?). "cmake -S . -B build && cmake --build build" should work on all OSes 07:38 < hebasto> I'm just list tested OSes :) 07:39 < hebasto> vasild: in general, you are right 07:39 < laanwj> going to try debian RV64 next 07:39 < vasild> :) 07:42 < hebasto> vasild: gist has been updated, thanks! 07:44 < vasild> any idea why the minisketch warnings are not observed when using autoconf? 07:45 < hebasto> did not check verbose logs yet 07:45 < vasild> ok 08:39 -!- belcher [~belcher@user/belcher] has joined #bitcoin-core-builds 09:01 < laanwj> builds on debian RV64 and FreeBSD were succesful, no tweaking required! 09:01 < hebasto> laanwj: thank you for testing! 09:02 < hebasto> RV64 means RiscV-64? 09:12 < fanquake> Are we going to migrate to cmake, or are we going to just end up with autotools + cmake? That is what it's looking like at the moment, and I'm not sure that is an improvement. 09:12 < fanquake> What is the plan for deprecating autotools, if that is what we are going to do? 09:12 < fanquake> Are we going to switch depends packages that support cmake, to use it? 09:13 < hebasto> depends do not use autotools, just pure makefiles 09:13 < fanquake> the packages we build in depends use autotools 09:13 < fanquake> ? 09:14 < fanquake> That's primarily how they are able to be cross-compiled 09:14 < sipa> Does that necessarily need to be changed at the same time? 09:15 < sipa> Presumably some of our depends packages don't provide cmake build systems. 09:15 < hebasto> it looks orthogonal for me as we do not support packages' build systems 09:15 < fanquake> Not necessarily, but it means it's not a migrations to cmake, it's just autotools + cmake 09:15 < laanwj> hebasto: correct 09:15 < fanquake> Basically you now need 2 build systems where you previously needed two 09:15 < fanquake> *needed 1 09:15 < laanwj> i'd say switch to cmake completely 09:15 < fanquake> hebasto: what do you mean by "as we do not support packages' build systems" ? 09:16 < sipa> I mean... we'll need whatever build system is used for whatever dependencies we have, inevitably. 09:16 < laanwj> i don't see the point of keeping the autotools system once cmake fully works 09:16 < laanwj> clearly, we're not there yet 09:16 < sipa> If a package only provides autotools based building, we'll inevitably need to use that. I don't feel like that's relevant in this discussion. 09:16 < laanwj> oh sure, packages in depends might use *any* build system 09:16 < hebasto> we already use cmake for some packages in depends 09:16 < laanwj> right it's not relevant to what bulid system we use ourselves 09:16 < fanquake> sipa: yes, but if the plan is to move to using cmake, I don't see why we aren't switching packges that support both first 09:16 < laanwj> correct 09:17 < laanwj> fanquake: could do that at the same time, good idea 09:17 < fanquake> it's relevant in that all of the build needs to exist in our release environments 09:17 < fanquake> *build infrastrcture 09:18 < hebasto> fanquake: it is not guaranteed that _all_ depends packages support cmake 09:18 < hebasto> however, I did not check 09:18 < fanquake> obviously, but the ones you need for a bare minimum build do 09:18 < fanquake> which is just libevent 09:18 < laanwj> the build environment will need both cmake and autotools, but afaik it already does for a depends build? 09:18 < hebasto> ^ yes 09:18 < laanwj> for a non-depends build only cmake is required after the switch 09:19 < fanquake> for a depends build currently, but only for macos iirc? and that should be going away 09:20 < fanquake> I can just see this ending up in a situation of us having to maintain /keep in sync 2 build systems, for x years, and it being quite a mess 09:20 < laanwj> but we don't need to maintain the depends packages' build systems, not really 09:21 < fanquake> I mean our main autotools build system 09:21 < fanquake> or would the plan be to delete it entirely if cmake is introduded? 09:21 < laanwj> imo that should be switched over in one go 09:21 < sipa> That should go away, as I understand it. 09:21 < laanwj> no intermediate phase 09:21 < laanwj> right 09:21 < hebasto> agree 09:21 < fanquake> right, so no backwards compat at all then? 09:21 < sipa> If we're not going to get rid of our autotools build system, we shouldn't switch over. 09:21 < laanwj> i agree having two build systems is bad 09:21 < fanquake> just a one time switch 09:21 < laanwj> yes 09:21 < laanwj> it can probably replace the msvc stuff too 09:21 < sipa> But that's independent of anything in depends, or the build systems used there. 09:22 < fanquake> I don't want two build systems, but basically breaking every existing build is not ideal 09:22 < laanwj> as cmake can generate MSVC build files 09:22 < laanwj> could always add some compat script? 09:22 < laanwj> that maps autofoo options to cmake and calls cmake 09:22 < sipa> It needs to work for all our supported systems. Until it does, we should not switch over. 09:22 < laanwj> right 09:23 < fanquake> Yes, the cmake system also has to implement every build option we currently have 09:23 < laanwj> yes 09:23 < sipa> yes 09:23 < laanwj> it should be feature equivalent 09:25 < laanwj> in a sense we already have two build sytems (autotools, msvc), i hope we can bring this down to one (cmake) 09:25 < fanquake> Wait, it's still not "just cmake" in any case 09:25 < fanquake> because we call out to autotools for libsecp 09:25 < fanquake> https://github.com/hebasto/bitcoin/commit/c8f401f72035ab8aa089039ba266b7c09c2a0b25 09:26 < laanwj> yes, we need cmake for libsecp too 09:26 < laanwj> there was dsicussion about this somewhere 09:26 < fanquake> right, so is that underway upstream already i take it? 09:26 < sipa> if someone writes it, i'm even ok with having both cmake and autotools for libsecp in parallel for a while 09:26 < sipa> real_or_random: ? 09:27 < sipa> not that i know of, but i expect it's pretty simple 09:27 < sipa> (to someone who knows build systems) 09:28 < laanwj> yes, it's trivial compared to bitcoin core's at least! 09:28 < fanquake> I see the last time it was proposed the chances of it being merged were "not high". 09:28 < fanquake> https://github.com/bitcoin-core/secp256k1/pull/761 09:28 < fanquake> hopefully that might have changed 09:29 < sipa> very different context, if the idea is to switch bitcoin core, and someone is actually doing the work to make that happen 09:29 < fanquake> Cool, maybe we should revive that branch then 09:30 < hebasto> ^ +1 09:30 < fanquake> Or, a from scratch write is probably just as easy at this point 09:30 < fanquake> I think that should almost be a blocker for our switch tbh 09:34 < laanwj> yes, would be good to have secp256k1 cmake merged first 09:40 < fanquake> heh. just tested that branch on a macos machine and it's built me a macos binary that seems to think it's going to run on linux 09:40 < vasild> I would even suggest to delete the autotools build system now and then figure out the cmake stuff... ;-D 09:40 < fanquake> it's looks for a linux data dir on startup 09:41 < hebasto> cmake project update -- https://github.com/hebasto/bitcoin/commits/cmake/0607-cross now cross compiles for all supported platforms 09:41 < fanquake> thought it was weird that it didn't fail when trying to get the data dir lock, but when trying to bind the RPC 09:42 < fanquake> so the binaries "compile", but are broken 09:42 < hebasto> fanquake: on macos natively compiled? 09:42 < fanquake> yes 09:45 < hebasto> headers are not configured properly yet 09:46 < fanquake> which headers? 09:47 < fanquake> in the gist it says native compiling has been tested on "macOS Monterey", or am I missing something? 09:47 < hebasto> I mean `config/bitcoin-config.h` 09:48 < hebasto> build process tested, not running of executables 09:51 < fanquake> I see. So is the plan to recreate the autoconf checks in cmake to get the equivalent defines? 09:51 < hebasto> yes 10:31 < davidbakin> this is excellent work and I'm looking forward to it! CMake is ugly (syntax is baroque and seemingly arbitrary in places) but it is rapidly becoming the defacto standard for C++ development meaning familiarity with it is increasing in the dev community; it is under active and positive continuing development; it has excellent documentation, and you can actually read and understand 10:31 < davidbakin> the build scripts. I would actually have a chance with CMake to figure out what I needed to do to get something done I hadn't accomplished before. automake: no way, it actually fails on ALL these points. Thank you! 10:33 < hebasto> autotools are good, they serve us so many years :) 10:35 < hebasto> vasild: minisketch subtree cmake build fixed 10:35 < davidbakin> ok, give it a nice certificate it can hang on its wall, pat it on the back for a job well done, and open the door for it ... 10:35 < hebasto> davidbakin: working on it... 10:35 < davidbakin> ty ty!! 10:44 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds 10:49 < vasild> hebasto: minisketch fixed here https://github.com/hebasto/bitcoin/commits/cmake/0607-cross ? will test it tomorrow 11:45 -!- real_or_- [~real_or_r@user/real-or-random/x-4440763] has joined #bitcoin-core-builds 11:46 -!- josibake__ [sid509132@id-509132.helmsley.irccloud.com] has joined #bitcoin-core-builds 11:46 -!- fjahr_ [sid374480@id-374480.uxbridge.irccloud.com] has joined #bitcoin-core-builds 11:46 -!- glozow_ [sid453516@user/glozow] has joined #bitcoin-core-builds 11:50 -!- real_or_random [~real_or_r@user/real-or-random/x-4440763] has quit [Ping timeout: 248 seconds] 11:50 -!- josibake_ [sid509132@id-509132.helmsley.irccloud.com] has quit [Ping timeout: 248 seconds] 11:50 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has quit [Ping timeout: 248 seconds] 11:50 -!- glozow [sid453516@user/glozow] has quit [Ping timeout: 248 seconds] 11:50 -!- glozow_ is now known as glozow 12:09 -!- theStack [~theStack@95.179.145.232] has quit [Remote host closed the connection] 12:17 < hebasto> vasild: the latest update is https://github.com/hebasto/bitcoin/commits/cmake/0607-minisketch 13:07 -!- belcher [~belcher@user/belcher] has quit [Quit: Leaving] 13:41 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Read error: Connection reset by peer] 14:12 -!- MacroFake [~none@72.5.34.65] has quit [Ping timeout: 244 seconds] 14:56 < hebasto> theStack: re "13:49:56 hebasto: tried your cmake branch cmake/0607 on OpenBSD 7.1, currently it fails building libsecp256k1 (https://pastebin.com/GUzfNM25)" -- Build instructions for OpenBSD have been added to https://gist.github.com/hebasto/aac97d2f6b18c4ec2ad951baeb1ac00c 15:12 -!- MacroFake [~none@72.5.34.65] has joined #bitcoin-core-builds 15:19 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-builds 18:30 -!- theStack [~theStack@95.179.145.232] has quit [Ping timeout: 258 seconds] --- Log closed Wed Jun 08 00:00:46 2022