On Wed, May 2, 2018 at 5:44 PM, Robert Haas <robertmh...@gmail.com> wrote: > I don't think that unsubstantiated hyperbole is the right way to > approach the task of convincing the community to adopt the approach > you prefer. I don't see that any compelling evidence has been > presented that a cmake-based solution would really save thousands of > lines of code.
Let me try to list the advantages as I see them. * ability to use ninja ** meson's requirement to use ninja might be a disadvantage but ability to use is definitely good ** faster than make - the difference is really noticeable ** good dependency story, parallel everything ** simply a very nice developer experience, for example the screen is not filled with scrolling lines instead progress updates shown as x/y files to go, currently at file z; try it and you'll see what I mean ** I got interested in the ninja for PG and therefore CMake or meson after trying clang-cl.exe for PG on Windows. clang-cl.exe is a drop in open source replacement for Microsoft's cl.exe but using it does not interact well with the fact that MSBuild runs only one cl.exe with lots of .c files as input and expects cl.exe to handle the parallelism while clang-cl.exe does not handle any parallelism taking the position that the build system should handle that. Being able to invoke clang-cl.exe from ninja instead of MSBuild would make fast compilation with clang-cl.exe easy while now only slow serial compilation is possible. * IDE integration: ** cmake and meson can generate XCode and Visual Studio, granted Visual Studio already works via the MSVC scripts ** CLion can consume cmake giving a good IDE story on Linux which PG currently lacks * get rid of the ad-hoc MSVC generation Perl scripts ** granted, I looked at those recently in the clang-cl context above and they're reasonably understandable/approachable even without knowing too much Perl * appeal to new developers ** I think it's not a controversial statement that, as time passes, autotools and make syntax are seen more and more as arcane things that only old beards know how to handle and that the exciting stuff moved elsewhere; in the long run this is a real problem ** on the other hand, as an autotools almost complete novice, after reading some autotools docs, I was pleasantly surprised at how small and easy to follow Andres' build patch adding LLVM and C++ support was, especially as it's doing big, non conventional changes: add support for another compiler but in a specific "emit LLVM bitcode" mode, add support for C++ etc. So autoconf ugliness is not that big of a deal but perception does matter. * PGXS on Windows ** could be solvable without moving wholesale >From the above, I would rate ninja as a high nice to have, IDE, PGXS on Windows and new developers as medium high nice to haves (but see below for long term concerns) and no MSVC Perl scripts as low nice to have. I started the thread as it seemed to me energy was consumed to move to another system (proof of concept and discussions) while it wasn't even clarified whether a new system isn't a complete no go due to the old platforms PG supports. I find Tom's and Robert's position of "acceptable but we would need to see real benefits as there definitely are real downsides" perfectly reasonable. The build system dictating platform support would indeed be the tail wagging the dog. Personally, with the current information I'd not vote for switching to another system, mainly because I ultimately think developer convenience should not trump end user benefits. I do have a real concern about the long term attractiveness of the project to new developers, especially younger ones as time passes. It's not a secret that people will just avoid creaky old projects, and for Postgres old out of fashion things do add up: autoconf, raw make, Perl for tests, C89, old platform support. I have no doubt that the project is already loosing competent potential developers due to this. One can say this is superficial and those developers should look at the important things but that does not change reality that some will just say pass because of dislike of the old technologies I mentioned. Personally, I can say that if the project were still in CVS I would probably not bother as I just don't have energy to learn an inferior old version control system especially as I see version control as fundamental to a developer. I don't feel the balance between recruiting new developers and end user benefits tilted enough to replace the build system but maybe in some years that will be the case.
