| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Hartmut Holzgraefe <hartmut(dot)holzgraefe(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Yuriy Zhuravlev <stalkerg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Is a modern build system acceptable for older platforms |
| Date: | 2018-05-02 21:58:01 |
| Message-ID: | 20180502215801.awej3ig2lwp6w3yy@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-05-02 23:43:50 +0200, Hartmut Holzgraefe wrote:
> On 02.05.2018 17:44, Robert Haas wrote:
> > But having parallel make work better and more efficiently
> > and with fewer hard-to-diagnose failure modes would definitely be
> > nice.
>
> that's especially a thing I haven't seen in "our" environment,
> this was an area where autotools and cmake didn't really differ,
> at least not for the Unix/Makefile side of things.
Recursive make like ours can't do full parallelism because dependencies
can't be fully expressed. With cmake that's not an issue. And its ninja
generator ends up being considerably faster than makefiles.
Now you could argue that we could just rewrite to non-recursive
make. But that'd be nearly as much work as migrating to another
buildsystem.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-05-02 22:08:09 | Re: Optimize Arm64 crc32c implementation in Postgresql |
| Previous Message | Thomas Munro | 2018-05-02 21:47:38 | Re: Optimize Arm64 crc32c implementation in Postgresql |