Hi, On 2021-10-12 15:30:57 +0200, Peter Eisentraut wrote: > I played with $subject a few years ago and liked it. I think, like you > said, meson is the best way forward. I support this project.
Cool. > One problem I noticed back then was that some choices that we currently > determine ourselves in configure or the makefiles are hardcoded in meson. Yea, there's some of that. I think some degree of reduction in flexibility is needed to realistically target multiple "backend" build-system like visual studio project files etc. but I wish there were a bit less of that nonetheless. > For example, at the time, gcc on macOS was not supported. Meson thought, if > you are on macOS, you are surely using the Apple compiler, and it supports > these options. I'm pretty sure this one now can just be overridden with CC=gcc. It can on linux and windows, but I don't have ready interactive access with a mac (leaving cirrus asside, which now has a "start a terminal" option...). > For example, the shared library build behavior has been carefully tuned in > opinionated ways. With the autotools chain, one can override anything with > enough violence; so we have always felt free to do that. I haven't followed > it in a while, so I don't know what the situation is now; but it is a > concern, because we have always felt free to try new and unusual build tools > (Sun compiler, Intel compiler, clang-when-it-was-new) early without waiting > for anyone else. It's possible to just take over building e.g. shared libraries ourselves with custom targets. Although it'd be a bit annoying to do. The bigger problem is that that e.g. wouldn't play that nicely with generating visual studio projects, which require to generate link steps in a certain way. It'd build, but the GUI might loose some of its options. Etc. Greetings, Andres Freund
