On Fri, Feb 10, 2017 at 5:07 PM, Robert Haas <robertmh...@gmail.com> wrote:
> But also, I'm not really sure whether this conversion makes sense. I > mean, any build system is going to require some work, and accordingly > our present build systems require some work. cmake will require > different work, but not necessarily less. The current system has a > long history; we pretty much know it works. Switching will inevitably > break some things. Maybe we'll end up better off in the long term, > but maybe we won't. Things are pretty good now, so it seems like it > would be easy for them to get worse rather than better. If nothing > else, everybody who has to learn the new system either to use it for > development or because they are doing packaging will have to do some > amount of extra work as a result of any switch. > For what it's worth (even well-maintained) cmake is a usability regression from well-maintained autotools from syseng/packager perspective. Two anecdotes: - ./configure is much nicer from user perspective. Compare: ./configure --prefix=/bla --enable-foo --disable-bar --with-ssl=/opt/myssl cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_BLAH -DCMAKE_FOO -DCMAKE_WHO_KNOWS_WHAT:PATH=/opt/myssl - Things like set(_PYTHON3_VERSIONS 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0) <https://github.com/Kitware/CMake/blob/master/Modules/FindPythonInterp.cmake#L43> Guess what, on older cmake versions this list did not include anything older that 3.3, so it was failing with in-comprehensive generic "not found" error even though 3.4 was installed. With this "fix" somebody somewhere will be banging their head against the wall again once 3.8 is out. Overall, when things go wrong debugging cmake requires cmake knowledge, while autotools mostly require shell knowledge which is much more common (again, for sysadmins/packagers). So while cmake is better for developers it is usually worse off for packagers and advanced users. I'm not saying migration is not worth it, I'm pointing out costs of such migration. PS: I personally like Google's internal version of https://bazel.build/ a lot. I've never used open-source version but I presume it's similar. While it has many problems (Java, lack of popular IDE support, lack of popularity and, again, Java) good parts are rules are both machine- and human- readable and writable and generally easy to debug. I'm not bold enough to propose PostgreSQL to use it, but I'd be happy to see ideas from it to be used elsewhere. -- Vladimir Rusinov Storage SRE, Google Ireland Google Ireland Ltd.,Gordon House, Barrow Street, Dublin 4, Ireland Registered in Dublin, Ireland Registration Number: 368047
smime.p7s
Description: S/MIME Cryptographic Signature
