On 2/8/17 4:44 PM, Andres Freund wrote: >> Well, I find it a bit scary. If you do the big switch all at once, then >> you will have to dedicate the following 3 months to fixing complaints >> from developers and build farmers. > > That'll be the case just as well if we spread it out over two cycles, > except that we'll have it in multiple phases, and we run into the danger > of a half-done conversion.
They key term is "dedicated". I don't think anyone wants to spend 3 months doing nothing but fixing the build system. If we spread it over several releases and bring more people up to speed along the way, that looks more manageable. >> That would work if there were a single entry point into the build >> system. But in practice there are many, and every one of them is >> someone's favorite. It's unlikely that we will be able to enumerate all >> of them during patch review. > > Not sure what you mean with "entry point"? People have all kinds of expectations on how the build system behaves. It's not just ./configure; make; make install. All kinds of niche and edge cases have evolved over the years. Variables you can set, overrides, targets in some subdirectories, building in subdirectories and having it build another subdirectory first, testing this way and testing that way, testing with a custom locale or a custom database name, building before testing or not, testing without reinstalling, and so on and so on. You'd have to make sure at least some of that continues to work or be able to explain it away. And most of it is not really documented. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers