Supports master branch

[smellman]

• supports master branch build (use git hash when run update.sh)
• drop support for 9.5 in master branch because PostGIS 3.1.0alpha drop support 9.5

[ImreSamu]

my2c: for testing latest trunk/master - maybe we can adopt some ideas from

• https://github.com/postgis/postgis-build-env/blob/master/Dockerfile

see:

• ARG = [ GEOS : master ; Postgres : master ; GDAL : trunk ; Proj : master ]
  • https://github.com/postgis/postgis-build-env/blob/master/build.py#L8

[phillipross]

@ImreSamu There seems to be a few concepts encapsulated within the Dockerfile and build script you referenced. Could you explicitly point out some of the notions that you think would be helpful to provide some guidance and discussion points?

[ImreSamu]

@smellman ; @phillipross :

just an idea for discussing:

Now in the Postgis 3.0.0 release note - there is a sentence :

• "Additional features and enhancements enabled if you are running Proj6+, PostgreSQL 12, and GEOS 3.8.0"

but as I see our postgis/postgis:12-3.0 image has the earlier versions:

• GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 5.2.0, September 15th, 2018"

And using/testing the latest postgis:master with the old geos(3.7.1)/proj(5.2) is not usefull for everybody.

So when we build the latest postgis:master ; we have to choose which version will be push to the docker hub: A.) postgis:master + latest geos(3.8)/proj(7.0) release B.) postgis:master + geos:master + proj:master C.) postgis:master + old geos(3.7.1)/proj(5.2) release

in the ideal case ; the build script will be flexible. So if we choose and push the "A." version ; I can build the "B." or the "C." version with a simple make command.

so my theoretical question:

• the GEOS and the PROJ version is important or not ?

[smellman]

I just try A option now.

[ImreSamu]

@smellman: OK.

• The "A" is OK for me .. ( postgis:master + latest geos(3.8)/proj(7.0) release )

And later we can extend the docker script .. with the ARG parameter.

[smellman]

@ImreSamu I just note: I use GDAL with master branch. I can't find trunk branch.

[smellman]

I finished my work:

• @ImreSamu I try 'A option' but I stop to try alpine version.
• I remove /usr/local/lib/libSFCGAL.la because cmake raise warning and the file may break.

[ImreSamu]

@smellman: Thanks :+1:

• I need a few days for testing ( + first feedback)

[phillipross]

In addition to testing that @ImreSamu might be doing, it seems travis is not happy with the length of time necessary to do a full build of the image. Is there anything that can be done to reduce the build time?

[smellman]

I don't know travis spec but if it has more than 2 core CPU, using make -j2 or -j(cpu core size) is better. Also, I think use debian package for GDAL and SFCGAL if it possible. But GDAL requires old GEOS and Proj4, the mean the docker image install two versions(GEOS 3.7 and 3.8>, Proj4 5.x and 7.x>).

[smellman]

Oh, I merged make test but this will fail in this branch. I will fix it.

[ImreSamu]

@smellman : try make -j$(nproc --ignore=1) everywhere ..

-    && make \
+    && make -j$(nproc --ignore=1) \

[phillipross]

Travis docs say there are two cores, but it'd probably be better to use nproc as @ImreSamu illustrated above to dynamically set the parallel make job number. I'm just not sure how safe it is to build that way.

[smellman]

@ImreSamu @phillipross Thank you comments. I just try to build in macOS(Docker 10core) and Ubuntu 19.10(4core) now.

[ImreSamu]

@smellman : as I see ; my suggestion is not working on travis :( 2 cores; no SMT on the travis ;

+ nproc --ignore=1
+ make -j1

[smellman]

@ImreSamu Yes I just find same now in my 4 core laptop.

$ nproc
4
$ nproc --ignore=1
3

I will remove --ignore option.

[smellman]

Also, I try make check before make install but it fails to up postgres...(Is this comment removed? I check it from notify mail)

[ImreSamu]

@smellman :

I try make check before make install but it fails to up postgres

I have also tested, and realized .. that need more work ( so I have removed my comment ) in theory it is a good idea, but in practice ...

[smellman]

@ImreSamu I think alpine version will need make check too when we resolve make check issue.

[phillipross]

This PR is shaping up nicely, good work 👍

Is there still more to be done? more testing? or is this ready to be merged?

[smellman]

@phillipross I don't have more task. But I think add nproc in alpine after this PR merged.

[ImreSamu]

@smellman: thanks, it is a good work! :+1:

[Komzpa]

You can use make -j without numbers to run "as much as possible". That works reasonably well except for the cases when build machine is tiny and things get out of memory, for that memory hog softwares you want to pin something like -j4 anyway.