Re: make install getting slower

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: make install getting slower
Date: 2018-12-07 17:34:42
Message-ID: B35EFA4D-74F0-4106-914A-1E10E945D450@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On December 7, 2018 8:04:10 AM PST, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>On 04/12/2018 21:56, Andres Freund wrote:
>> As a comparison, I'd a tree that had the cmake patchset applied
>around
>> (~1.5 yo tree). Using the ninja generator gets a clean build to
>> 0m0.073s, a first install to 0m0.201s and a repeat install to
>0m0.170s.
>
>Yeah, I've been playing with meson+ninja, and those run times are
>amazing.

It's not just the the faster times due to better tools, a non recursive implementation also allows for much cleaner dependencies then we have right now. Which also increases speed...

>I'm not confident whether a high-level build system generator like
>cmake
>or meson would ever give us the flexibility we need. I'm just thinking
>of the most recent episode where we had to override the timestamp
>handling of ranlib of macOS. There are many others like it.

I don't know much about meson, but I don't see why cmake can't handle that kind of thing.

>But I think that we realistically could generate ninja files using some
>Perl code not unlike the one that does the catalog .dat to .bki
>transformation. Just a thought at this point.

That seems not great, because we would lose the ability to generate mscv files from the same source. Or whatever the eventual replacement of ninja will be.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-07 17:52:56 Re: BUG #15541: Use after release in PQprint
Previous Message Tom Lane 2018-12-07 17:23:03 Re: Adding support for a fully qualified column-name in UPDATE ... SET