On 9/17/16 1:21 PM, Yury Zhuravlev wrote: > Now, I published the first version of the patch.
I tried this out. Because of some file moves in initdb and pg_basebackup, the build fails: [ 74%] Linking C executable initdb Undefined symbols for architecture x86_64: "_fsync_pgdata", referenced from: _main in initdb.c.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status make: *** [src/bin/initdb/CMakeFiles/initdb.dir/build.make:177: src/bin/initdb/initdb] Error 1 make: *** [CMakeFiles/Makefile2:2893: src/bin/initdb/CMakeFiles/initdb.dir/all] Error 2 make: *** [Makefile:128: all] Error 2 Please submit an updated patch. 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. Please supply some documentation, such as - what are the basic commands - how to set include/library paths, choose configure options - how to set CFLAGS - how to see raw build commands - what are the targets for all/world/check/docs etc. - explain directory structure 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. 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. The Python check appears to be picking up pieces from two different Python installations: -- Found PythonInterp: /usr/local/bin/python (found version "2.7.12") -- Found PythonLibs: /usr/lib/libpython2.7.dylib (found version "2.7.10") 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? 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. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers