Re: [HACKERS] WIP: About CMake v2 - Mailing list pgsql-hackers

From Yuriy Zhuravlev
Subject Re: [HACKERS] WIP: About CMake v2
Date
Msg-id CANiD2e9i3VGS-ri7AZaqCwArjfib7Q0AGPrUishQywTMvO3c4g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] WIP: About CMake v2  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
I don't understand what this has to do with cmake.  If this is a
worthwhile improvement for the Windows build, then please explain why,
with a "before" and "after" output and a patch for the existing build
system as well.
During the porting process, I meet such situations when I should fix something. It's happening because I build with different way also current build system is trying to avoid many sharp corners. 
If talk about this situation - without strict mode many "floats" checks don't work correctly. You can read the link above. Besides this option puts by build system. I think we can make a new thread for this approach. (with patch for current perl system) 

It might also be worth refactoring the existing Autoconf code here to
make this consistent.

I do it because it's convenient in CMake. I can change this it's not big deal.  

Please explain what the circular dependency is.  If there is one, we
should also side-port this change.

It's an important part.  I have a rule for generate rijndael.tbl by gen-rtab who make from rijndael.c (with special define) who include rijndael.tbl . 
If I generate rijndael.tbl it's to force build gen-rtab and generate rijndael.tbl again. 
CMake knows about "includes" in files but we can make the wraparound macro to hide include. 

This patch removes the uuid.h include but doesn't add it anywhere else.
How does it work? 

CMake sends to compiler right place for uuid.h (I mean -I/usr/include and etc for gcc).
 
Yeah, I think this is how the MSVC stuff effectively works right now as
well.

I glad to hear it.  

2017-01-03 17:11 GMT+03:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
On 12/30/16 9:10 AM, Yuriy Zhuravlev wrote:
> cmake_v2_2_c_define.patch
>
> Small chages in c.h . At first it is “#pragma fenv_access (off)” it is
> necessary if we use /fp:strict for MSVC compiler. Without this pragma we
> can’t calc floats for const variables in compiller time (2 * M_PI for
> example). Strict mode important if we want to be close with ieee754
> float format on MSVC (1.0 / 0.0 = inf for example).  Detail info here:
> https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

I don't understand what this has to do with cmake.  If this is a
worthwhile improvement for the Windows build, then please explain why,
with a "before" and "after" output and a patch for the existing build
system as well.

> Second change is because I find and set HAVE_INT128 directly from CMake.
> PG_INT128_TYPE used only for autoconfig scripts.

It might also be worth refactoring the existing Autoconf code here to
make this consistent.

(My assumption is that if we were to move forward with cmake or any
other build system change, we would have to keep the old one alongside
at least for a little while.  So any changes to the C code would need to
be side-ported.)

> cmake_v2_3_rijndael.patch
>
> First I added special wraparound because here CMake have circular
> dependency (cmake very smart here). Second I removed rijndael.tbl
> because it generated during build process every time.

Please explain what the circular dependency is.  If there is one, we
should also side-port this change.

> cmake_v2_4_uuid.patch
>
> Another small patch. Right place for uuid.h I find by CMake and not
> necessary this ifdef hell.

This patch removes the uuid.h include but doesn't add it anywhere else.
How does it work?

> Questions for discussion:
>
> In generated project by CMake we always have only one enter point. Also
> INSTALL macross support only including to “all” targets. It follows that
> it is impossible build contrib modules separately only with “all”
> target. Here write about this behavior:
> https://cmake.org/cmake/help/v3.7/prop_tgt/EXCLUDE_FROM_ALL.html

Yeah, I think this is how the MSVC stuff effectively works right now as
well.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Yuriy Zhuravlev
Date:
Subject: Re: [HACKERS] WIP: About CMake v2