Re: failing to build preproc.c on solaris with sun studio
От | Tom Lane |
---|---|
Тема | Re: failing to build preproc.c on solaris with sun studio |
Дата | |
Msg-id | 158349.1659834609@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: failing to build preproc.c on solaris with sun studio (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > On Sat, Aug 06, 2022 at 05:43:50PM -0700, Andres Freund wrote: >> Sure, we can hack around it in some way. But if we need such hackery to >> compile postgres with a compiler, what's the point of supporting that >> compiler? It's not like sunpro provides with awesome static analysis or such. > To have a need to decide that, PostgreSQL would need to grow preproc.o such > that it causes 55% higher RAM usage, and the sunpro buildfarm members extant > at that time would need to have <= 32 GiB RAM. I give a 15% chance of > reaching such conditions, and we don't gain much by deciding in advance. I'd > prefer to focus on decisions affecting more-probable outcomes. I think it's the same rationale as with other buildfarm animals representing niche systems: we make the effort to support them in order to avoid becoming locked into a software monoculture. There's not that many compilers in the farm besides gcc/clang/MSVC, so I feel anyplace we can find one is valuable. As per previous discussion, it may well be that gcc/clang are dominating the field so thoroughly that nobody wants to develop competitors anymore. So in the long run this may be a dead end. But it's hard to be sure about that. For now, as long as somebody's willing to do the work to support a compiler that's not gcc/clang, we should welcome it. regards, tom lane
В списке pgsql-hackers по дате отправления: