| From: | Yuriy Zhuravlev <stalkerg(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Hartmut Holzgraefe <hartmut(dot)holzgraefe(at)gmail(dot)com>, 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 04:16:58 |
| Message-ID: | CANiD2e-OGdOkeq2ZMW3mvCSNCLNN=8wPG=qkvAMW9GJet+do0Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> No tons of hacks.
>
And functions too
https://bitbucket.org/adunstan/pg-closed-ranges/raw/0475b50ff793ce876a78c96d72903c9793a98fc1/cmake/FindPostgreSQL.cmake
I mean things like HAVE_LONG_LONG_INT you can't figure out on "configure"
stage without parsing config.h in CMake. Also, maybe I am wrong but you
can't check 32/64 bit consistent between target postgres and your current
environment.
etc and etc
That would just add to the knowledge that developers and committers
> would need. "One more level of indirection" is rarely the right
> solution.
>
A lot of similar projects made this transformation and came to CMake, what
problem with Postgres?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Yuriy Zhuravlev | 2018-05-02 04:26:27 | Re: Is a modern build system acceptable for older platforms |
| Previous Message | Tom Lane | 2018-05-02 03:53:05 | Re: A few warnings on Windows |