Re: WIP: About CMake v2 - Mailing list pgsql-hackers

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
-DWITH_OPENSSL=OFF -DWITH_PYTHON=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.


regards


Mark



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[2]: *** [src/bin/initdb/CMakeFiles/initdb.dir/build.make:177:
> src/bin/initdb/initdb] Error 1
>   make[1]: *** [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.
>