On Wed, Oct 2, 2019 at 4:46 PM Andres Freund <and...@anarazel.de> wrote: > > The existing expectation is that we make our build tools in Perl. > > I'm sure Andres doesn't want to write a C parser in Perl, but > > poking around suggests that there are multiple options already > > available in CPAN. I'd much rather tell people "oh, there's YA > > module you need to get from CPAN" than "figure out how to install > > version XXX of LLVM". > > As far as I can tell they're all at least one of > 1) written in C, so also have build requirements (obviously a shorter > build time) > 2) not very good (including plenty unsupported C, not to speak of > various optional extensions we use, not having preprocessor support, > ...) > 3) unmaintained for many years.
I find this argument to be compelling. To me, it seems like having to install some random CPAN module is probably more likely to be a problem than having to install LLVM. For one thing, it's pretty likely that any given developer already has LLVM, either because they're using clang as their C compiler in general, or because their system has it installed anyway, or because they've built with JIT support at least once. And, if they haven't got it, their favorite packaging system will certainly have a build of LLVM, but it may not have a build of Parse::C::Erratically. Really, this has been a problem even just for TAP tests, where we've had periodic debates over whether it's OK for a test to depend on some new module that everyone may not have installed, possibly because they're running some ancient Perl distribution (and our definition of "ancient" might make a historian giggle) where it wasn't bundled with core Perl. Can we rewrite the test so it doesn't need the module? Do we just skip the test, possibly masking a failure for some users? Do we make it fail and force everybody to find a way to install that module? Just to be clear, I'm not in love with using LLVM. It's a big hairy piece of technology that I don't understand. However, it's also a very widely-supported and very capable piece of technology that other people do understand, and we're already using it for other things. I don't think we're going to do better by using something different and probably less capable and less well-supported for this thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company