Re: Setting rpath on llvmjit.so?

Поиск
Список
Период
Сортировка
От Yuriy Zhuravlev
Тема Re: Setting rpath on llvmjit.so?
Дата
Msg-id CANiD2e8YN1=YyL=D6QY7B9c2q1hgMvc0A7K7JnZCC6d1ejHZJQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Setting rpath on llvmjit.so?  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Built-in connection pooling
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS