--- Log opened Fri May 06 00:00:15 2022
02:19 < real_or_random> so there's real interest in cmake?
02:23 < real_or_random> Just wondering what it would mean for secp256k1... I guess we'd need to see. Autotools have been annoying in secp256k1, but I believe much less annoying than in Core, and they have handled cross-compilation usually well. And secp256k1 is much simpler (no deps for example). But people keep asking for cmake, and using the same build system would probably be nice for integration.
02:26 < real_or_random> Also we target a wider range of users, e.g, embedded, with sometimes strange compilers, etc. I could imagine autotools are more common there but I actually don't know.
02:28 < real_or_random> Whenever someone wanted to a CMake build system, we always argued that we don't want to maintain two system, and the current system works.
02:30 < real_or_random> But I'm not even sure about this... Of course maintaining build systems is annoying but one goal of secp256k1 to make it easy to integrate in many different systems.
02:32 < real_or_random> So it wouldn't absurd to think that that maintaining two build systems is a better use of time than squeezing out another 2%  of signing performance. In particular if the CMake build is easy to maintain...
02:32 < real_or_random> Anyway, many open questions. :D
02:33 < stick> real_or_random: we use libsecpk256k1 in the trezor firmware and we use scons for build
02:33 < fanquake> Certainly are. I think for libsecp256k1, the possibility to maintain both systems is much more straight forward compared to Core
02:33 < stick> i wouldn't worry that much about embedded, since most of the embedded build systems are so obscure
02:33 < real_or_random> stick: ah yes, I think I was aware
02:33 < stick> you'd need to recreate everything from scratch
02:34 < fanquake> In the case that Core were to migrate to CMake, having libsecp256k1 already using CMake would be great, otherwise our migration isn't autotools -> cmake, it's autotools -> autotools + cmake
02:34 < real_or_random> Yeah, so our goal for now is to make it really easy to build this without a build system. It's just two compiler invocations right now, and one or two -D flags.   
02:34 < fanquake> However I am waiting to see a Core CMake branch that does all it needs to, to be usable / very-near equivalent to our current autotools system, along with some sort of migration path
02:34 < real_or_random> And we want to reduce this further
02:35 < fanquake> I have questions in regards to cross-compilation, and how all that works in cmake, it seems like you get it less "out of the box" compared to autotools
02:35 < stick> fanquake: you could still have cmake stuff for secp256k1 maintained in the bitcoin tree and secp256k1 would only have autotools, but it's far from ideal
02:35 < fanquake> That is also why I suggested that before we try port our whole build  system, start by switching the depends packages that support autootools and cmake, i.e libevent, to use cmake, and see what sort of issues / etc we run into
02:36 < fanquake> if we can switch those packages in depends over easily enough, then cmake for the rest of the build system may also just be (fairly) straight forward
02:36 < real_or_random> Yeah, so I think secp256k1 could be another play ground for this
02:42 < real_or_random> cc sipa 
02:45 < laanwj> cross compilation in cmake is basically: create a toolchain file (a text file defining the paths to compilers, ar, linker, etc), then pass it with -DCMAKE_TOOLCHAIN_FILE=<file>
02:45 < laanwj> much less "magic" then autotools but also straighforward and unambigious
02:49 < laanwj> you can also pass the individual settings -DCMAKE_C_COMPILER=… etc manually to cmake 
02:49 -!- greypw2546 [~greypw254@grey.pw] has quit [Quit: I'll be back!]
02:49 -!- greypw2546 [~greypw254@grey.pw] has joined #bitcoin-core-builds
06:20 < sipa> I'd expect that secp256k1 under cmake (or really any build system) would be fairly easy now
06:20 < sipa> But I have no experience with cmake at all.
08:35 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
10:06 < dongcarl> Yeah the toolchain files look quite nice, hopefully they work as nice in practice for our usecases
10:08 < dongcarl> Don’t think we’ll need to convert everything all at once. CMake’s ExternalProject functionality should work with autotools (though how accurately vars are exported remains to be seen)
12:12 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 248 seconds]
13:02 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
13:45 < hebasto> another update about Bitcoin Core CMake-based build system -- https://github.com/hebasto/bitcoin/commits/cmake/0506
13:45 < hebasto> more details in https://gist.github.com/hebasto/aac97d2f6b18c4ec2ad951baeb1ac00c
13:46 < hebasto> tldr -- cross-compiling works nice, even `libbitcoinconsensus.dll` with `DEBUG=1`
14:11  * luke-jr wonders if it would be better for the macOS SDK gen-sdk to be deterministically different, to  more easily observe who actually extracted it themselves :P
14:12 < luke-jr> but I guess post-gitian, we no longer sign inputs anyway :/
15:58 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 248 seconds]
16:19 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has joined #bitcoin-core-builds
17:07 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500::12b] has quit [Ping timeout: 252 seconds]
17:38 < luke-jr> hebasto: upon further reflection, I can't think of a good reason to positively object to CMake (besides additional work) as long as the code is reasonable and a `configure` wrapper is provided (still prefer autotools for now tho)
--- Log closed Sat May 07 00:00:16 2022