--- Log opened Tue Oct 12 00:00:33 2021
02:59 -!- midnight [~midnight@user/midnight] has quit [Ping timeout: 265 seconds]
03:00 -!- midnight [~midnight@user/midnight] has joined #secp256k1
09:42 -!- cfields [~cfields@user/cfields] has joined #secp256k1
10:00 < cfields> real_or_random: From reading #988 and descending into #918 I'm having a bit of trouble following the plan for generating the static tables.
10:01 < cfields> real_or_random: for context, I'm going to experiment with tighter buildsystem integration with Core, similar to https://github.com/bitcoin/bitcoin/pull/22646
10:02 < cfields> but if the static generation is going to change significantly, I can hold off until that's done (or maybe help with it since we'll need a solution too).
10:08 < sipa> cfields: PR 956 probably gives you a good idea
10:08 < sipa> (it did the same, but for the other table)
10:12 < cfields> ok, so it'll continue to be native binaries outputting source on-the-fly? Just making sure I'm not missing any big generated files being committed.
10:16 < sipa> no, precomputed source code will be checked into the repo
10:16 < sipa> if you want customized, you can configure and rebuild, which does involve binaries
10:17 < sipa> but that can be done on separate machines, or just on one machine in a worktree where you first configure for native and generate, and then reconfigure and build for target
10:18 < sipa> so the complexity of having separate target and host envs in configure goes away
10:18 < cfields> aha, so I did miss that part. I was hoping that'd be the answer.
10:19 < cfields> thanks!
10:19 < cfields> will take a look in more detail.
10:20 < sipa> and bitcoin core's side will just use the defaults, i imagine (as would most intended users)
10:20 < cfields> so I suppose Core will be able to use the static files?
10:20 < cfields> heh, ok.
10:20 < cfields> s/static/checked-in/
10:20 < sipa> yes
10:21 < cfields> great, that should make life much easier.
10:22 < sipa> currently there is ecmult_static_pre_g.h for the verification table; the ongoing work is about doing the same for the signing table
10:23 < sipa> the version subtreed into bitcoin core doesn't have this yet
10:26 < cfields> ack, I'll just work with the assumption that they'll both be done that way.
15:12 < real_or_random> cfields: right, the goal is really to get rid of the dynamic generation... or let's say the binaries become developer/maintainer tools that the user won't need 
15:14 < real_or_random> and indeed, it was getting more and more annoying to maintain the build system with the need to compile not only for the target machine but also for the build machine 
15:23 < cfields> real_or_random: yeah, that's great. fwiw, I agree with you about python as a dependency. That seems like a lateral move at best imo. But committing the most common impls sounds like a great solution.
15:26 < real_or_random> sipa gmaxwell andytoshi: it would be nice to hear your opinion on https://github.com/bitcoin-core/secp256k1/pull/988#issuecomment-938650194 ... also wrt rust-secp256k1 which I believe is the main user user of  _context_no_precomp  
20:19 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Quit: Leaving]
20:20 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #secp256k1
--- Log closed Wed Oct 13 00:00:34 2021