|From:||Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org|
|Cc:||Michael Paquier <michael(dot)paquier(at)gmail(dot)com>|
|Subject:||Re: WIP: About CMake v2|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
I had a bit a play around to see if I could get this building properly
again with v10 (i.e master). I've attached a minimal *incremental* patch
that needs to be applied after v1. This gets everything under the src
tree building (added the new file_utils.c and reordered some link libs
and removed some duplicates).
I haven't made any changes with respect to it trying to detect and build
everything. One added nit I see is that unless I'm missing something
there appears to be no way to stop it trying to build all the
contribs...so an option to enable/disable their build is needed.
To make it display what options there are I use:
$ mkdir build; cd build ; cmake .. -LH
And to do a build that works:
$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local/pgsql/10 -DWITH_PERL=OFF
With reference to Tom's comments, I'm thinking that these should all
default to 'OFF' plus an additional variable WITH_CONTRIB (or similar)
should default to OFF too.
On 09/11/16 08:37, Peter Eisentraut wrote:
> 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
> 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.
|Next Message||Etsuro Fujita||2016-11-16 02:55:03||Re: Push down more UPDATEs/DELETEs in postgres_fdw|
|Previous Message||Kohei KaiGai||2016-11-16 01:33:03||Use of pg_proc.probin is legal?|