Re: Setting rpath on llvmjit.so?

From: Yuriy Zhuravlev <stalkerg(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Setting rpath on llvmjit.so?
Date: 2018-04-18 10:16:15
Message-ID: CANiD2e8YN1=YyL=D6QY7B9c2q1hgMvc0A7K7JnZCC6d1ejHZJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

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