On Fri, Jan 04, 2019 at 02:36:15PM -0800, Andres Freund wrote: > Hi, > > On 2019-01-04 16:43:39 -0500, Tom Lane wrote: > > Joerg Sonnenberger <jo...@bec.de> writes: > > >> * What's the generator written in? (if the answer's not "Perl", wedging > > >> it into our build processes might be painful) > > > > > Plain C, nothing really fancy in it. > > > > That's actually a bigger problem than you might think, because it > > doesn't fit in very nicely in a cross-compiling build: we might not > > have any C compiler at hand that generates programs that can execute > > on the build machine. That's why we prefer Perl for tools that need > > to execute during the build. However, if the code is pretty small > > and fast, maybe translating it to Perl is feasible. Or perhaps > > we could add sufficient autoconfiscation infrastructure to identify > > a native C compiler. It's not very likely that there isn't one, > > but it is possible that nothing we learned about the configured > > target compiler would apply to it :-(
There is a pre-made autoconf macro for doing the basic glue for CC_FOR_BUILD, it's been used by various projects already including libXt and friends. > I think it might be ok if we included the output of the generator in the > buildtree? Not being able to add keywords while cross-compiling sounds like > an acceptable restriction to me. I assume we'd likely grow further users > of such a generator over time, and some of the input lists might be big > enough that we'd not want to force it to be recomputed on every machine. This is quite reasonable as well. I wouldn't worry about the size of the input list at all. Processing the Webster dictionary needs something less than 0.4s on my laptop for 235k entries. Joerg
