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