From: Yury Zhuravlev <u.zhuravlev@postgrespro.ru>
To: <pgsql-hackers@postgresql.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Subject: Re: WIP: About CMake v2
Date: Tue, 08 Nov 2016 23:40:57 +0300
MIME-Version: 1.0
Message-ID: <6cd3400f-a1bd-40ac-b2c9-e7e221f548eb@postgrespro.ru>
In-Reply-To: <af9694db-858b-c15a-9c5a-bcbccf933ca0@2ndquadrant.com>
References: 
 <CAPfS4ZzwscpK2MeE73==wBOAMndW1UuvktSL6TqXAatok+WHzg@mail.gmail.com>
 <CAPfS4Zw8UReHG12RmpYYb3REqSN7Knx8coXg5_oT35HfCwggww@mail.gmail.com>
 <CAB7nPqThtTWyh4vaYSjwm=Q_nAJzVbo=_F9nkPmA68v6bD38Kw@mail.gmail.com>
 <29526280-50e2-495b-99e1-ccd4e16ffd05@postgrespro.ru>
 <CAB7nPqSWtRhZDYuFVy5jBd8AOjdNiwwM8B9fazKArZs2Hd+rWA@mail.gmail.com>
 <CAB7nPqTHwOT7WfV33ywyFS6NhSEr46C+S6jWS3sR20UDN7XP0w@mail.gmail.com>
 <5a8a9610-722f-49df-b609-35842fe4c8d6@postgrespro.ru>
 <CAB7nPqR_Cxv67kOOOQjrKx9cvc5Yn=9wzJyFoLxdc_qj2+TU9w@mail.gmail.com>
 <0d8bf7e7-db42-44d8-aac5-65ff407cb60f@postgrespro.ru>
 <af9694db-858b-c15a-9c5a-bcbccf933ca0@2ndquadrant.com>
Organization: postgrespro
User-Agent: Trojita/v0.6-216-g795fa33; Qt/5.7.0; xcb; Linux;
 Gentoo Base System release 2.3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Hello.

Peter Eisentraut wrote:
> I tried this out.  Because of some file moves in initdb and
> pg_basebackup, the build fails:
Yes, I need rebase patch to latest master. I do it as soon as possible.=20
Also I have some new achievements.=20

>I suggest you use git format-patch to produce patches.  This is easier
>to apply, especially when there are a lot of new files involved.  Also
>use the git facilities to check for whitespace errors.
I agree.=20

>I suggest for now you could put this into a README.cmake file in your
>patch.  We don't need to commit it that way, but it would help in the
>meantime.
Good idea, currently I write all documentation on github. I will try to=20
move it to patch.=20

>When I run cmake without options, it seems to do opportunistic feature
>checking.  For example, it turns on OpenSSL or Python support if it can
>find it, otherwise it turns it off.  We need this to be deterministic.
>Without options, choose the basic feature set, require all other
>features to be turned on explicitly, fail if they can't be found.
>Whatever the Autoconf-based build does now has been fairly deliberately
>tuned, so there should be very little reason to deviate from that.
This approach I see only in Postgres project and not fully understood.
Can you explain me more what reasons led to this approach?
Not big deal to make behavior like postgres Autoconf but I think it's=20
important clear view here.=20

>The Python check appears to be picking up pieces from two different
>Python installations:
Ooops you right. For Python detecting I use standard CMake module and
his behavior depending on CMake version. We should really careful here.

>The check results otherwise look OK, but I'm a bit confused about the
>order.  It checks for some functions before all the header files are
>checked for.  Is that intentional?
I have plans to change order checks.=20

>There are a number of changes in .[ch] and .pl files that are unclear
>and not explained.  Please explain them.  You can also submit separate
>preliminary patches if you need to do some refactoring.  Ultimately, I
>would expect this patch not to require C code changes.
I suppose separate patches with comments will be best way. I will do it.
I think we can talks about details after that.

Big thanks for your remarks it's very important for me and this "small"=20
project.
I will try to do all tasks quickly.

Best regards.=20

--=20
Yury Zhuravlev
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers