Re: Setting rpath on llvmjit.so? - Mailing list pgsql-hackers

From Yuriy Zhuravlev
Subject Re: Setting rpath on llvmjit.so?
Date
Msg-id CANiD2e8YN1=YyL=D6QY7B9c2q1hgMvc0A7K7JnZCC6d1ejHZJQ@mail.gmail.com
Whole thread Raw
In response to Re: Setting rpath on llvmjit.so?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Well, before it does everything, there's little point in reviewing
>  whether it's mergeable or not.

For this significant case, it's not working as you expect.
First, Postgres community should find consensus about migration to CMake (or alternative). Now, this project too huge to work on it without sure in importance.
Second, a few main contributors should start helping to fix bugs and deep into architecture. It's very important because build system very tightly bound with all source code and one man can't know all rarely cases. Moreover, it's needed to understand some restriction CMake (and another project generators) and find consensus in the community about it. For example why we can't build contrib modules independent on main postgres with CMake. 
Also, you should understand what you can't keep the whole feature set and behaviors in the new build system, postgres too big for this now (probably you will have many new features but you will lose too). It's why main contributors should know new build system to find solutions and consensus for decisions.

We can open a new thread for discussion about the first question, the second question should be later. 

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Built-in connection pooling
Next
From: Craig Ringer
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS