Re: WIP: About CMake v2

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.
Also I have some new achievements.

>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.

>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
move it to patch.

>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
important clear view here.

>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.

>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"
project.
I will try to do all tasks quickly.

Best regards.

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