Re: WIP: About CMake v2

>
> 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(dot)eisentraut(at)2ndquadrant(dot)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
>