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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
