--- Log opened Mon Jun 27 00:00:04 2022
02:02 -!- darosior [~darosior@194.36.189.246] has quit [Quit: darosior]
02:22 -!- darosior [~darosior@194.36.189.246] has joined #secp256k1
03:15 < real_or_random> I know we NACKed CMake in the past but I'm open to it. Given that this has been used a few times, I think our users would benefit. It seems that the lack of support for CMake drives a few potential users away because they don't want to bother with autotools  
03:17 < real_or_random> And one of our main goals is really to see wide use of the library in the ecosystem. Maintaining a build system is kinda boring but I bet the positive impact for users is larger than squeezing another a few percents of  performance
03:18 < hebasto> which the oldest system libsecp256k1 does support now? asking to choose minimum CMake version
03:19 < real_or_random> And if we get some initial support from our parent project and some (tiny) commitment to help us keep it alive, this is much better story than having a PR by a first-time contributor for which we don't know whether they help maintaining it
03:21 < real_or_random> We should just not declare it a goal that the build systems have feature parity. The library is simple but autotools can be massaged to work with a lot of targets and compilers, etc. There's no need to duplicate all of this.
03:22 < real_or_random> Something like this https://github.com/microsoft/vcpkg/blob/master/ports/secp256k1/CMakeLists.txt or what Core has as a starting point is good. We anyway strive for easy configuring with #defines. People can then at least add -D flags easily 
03:23 < real_or_random> hebasto: you mean compile target?
03:23 < real_or_random> s/Given that this has been used a few times/Given that this has asked for a few times
03:23 < hebasto> real_or_random: no, build system
03:24 < hebasto> * builder system
03:26 < hebasto> in Bitcoin Core, the goal is to be able to build at least on Ubuntu 18.04
03:28 < real_or_random> oh ok... I believe https://github.com/bitcoin-core/secp256k1/blame/44c2452fd387f7ca604ab42d73746e7d3a44d8a2/configure.ac#L1 is not a lie but I haven't checked in a while :)
03:30 -!- darosior [~darosior@194.36.189.246] has quit [Quit: darosior]
03:31 < hebasto> I see
03:31 < real_or_random> hebasto: ah no, https://github.com/bitcoin-core/secp256k1/blob/master/configure.ac#L30 this is probably the much more recent restriction
03:32 < real_or_random> or not... 2011. well, anyway, the answer is "pretty old" 
03:35 < hebasto> real_or_random: re "There's no need to duplicate all of this." -- Do you mean to skip experimental features?
03:37 < real_or_random> not necessarily. rather "complicated" configs. if this special thing someone wants to do is much better done with autotools, then I think we should just point them to autotools (or maybe even the other way around)  
03:38 < real_or_random> Those things can be experimental or not. For example, I think experimental *modules* are not an issue for the build system. The experimental ARM support could be much trickier
03:47 -!- darosior [~darosior@194.36.189.246] has joined #secp256k1
03:54 < hebasto> re "or not... 2011. well, anyway, the answer is "pretty old"  -- from https://repology.org data I assume that Debian 8 could be a good model builder system, no?
03:58 < real_or_random> hehe maybe. not sure if we really care about these old systems, they just happen to work
05:03 < sipa> At some point, sufficiently old systems are probably more easy to get working by building by hand rather than using a build system.
06:56 -!- halosghost [~halosghos@user/halosghost] has joined #secp256k1
--- Log closed Tue Jun 28 00:00:05 2022