openbsd-ports/geo/pgrouting/Makefile

# $OpenBSD: Makefile,v 1.24 2018/09/30 11:46:43 landry Exp $

COMMENT =	geospatial routing extension for PostgreSQL

V =		2.6.1
DISTNAME =	pgrouting-${V}
MASTER_SITES =	https://github.com/pgRouting/pgrouting/releases/download/v${V}/

CATEGORIES =	geo databases

HOMEPAGE =	http://pgrouting.org/

MAINTAINER =	Landry Breuil <landry@openbsd.org>

# GPLv2
PERMIT_PACKAGE_CDROM=	Yes

WANTLIB +=	CGAL boost_system-mt boost_thread-mt gmp m pthread
WANTLIB +=	boost_atomic-mt boost_chrono-mt boost_date_time-mt ${COMPILER_LIBCXX}

MODULES =	databases/postgresql devel/cmake
COMPILER =	base-clang ports-gcc

LIB_DEPENDS =	math/cgal
RUN_DEPENDS =	geo/postgis
BUILD_DEPENDS =	databases/postgresql,-server
TEST_DEPENDS =	${BUILD_PKGPATH}
TEST_ENV =	LD_PRELOAD=libpthread.so
SUBST_VARS =	V
MODPOSTGRESQL_TEST_CMD = \
	cd ${WRKSRC}; \
	./tools/testers/algorithm-tester.pl

.include <bsd.port.mk>
Update to pgrouting 2.6.1 2018-09-30 11:46:43 +00:00			`# $OpenBSD: Makefile,v 1.24 2018/09/30 11:46:43 landry Exp $`
Import pgrouting 2.0.0 pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality. Advantages of the database routing approach are: * Data and attributes can be modified by many clients, like QGIS and uDig through JDBC, ODBC, or directly using Pl/pgSQL. The clients can either be PCs or mobile devices. * Data changes can be reflected instantaneously through the routing engine. There is no need for precalculation. * The "cost" parameter can be dynamically calculated through SQL and its value can come from multiple fields or tables. ok sthen@ 2014-12-16 21:34:35 +00:00
			`COMMENT = geospatial routing extension for PostgreSQL`

Update to pgrouting 2.6.1 2018-09-30 11:46:43 +00:00			`V = 2.6.1`
Update to pgrouting 2.6.0. Switch to real releases hosted on github while here. 2018-04-01 18:44:59 +00:00			`DISTNAME = pgrouting-${V}`
Actually switch to 'real' uploaded tarballs and not git-autogenerated ones, thanks to upstream. Checksum/size doesnt change so no need to append the _1 suffix. Cf https://github.com/pgRouting/pgrouting/issues/1013 2018-04-05 15:05:21 +00:00			`MASTER_SITES = https://github.com/pgRouting/pgrouting/releases/download/v${V}/`
Add patch to work with PostgreSQL 10. OK pea@ 2017-11-30 16:23:07 +00:00
Import pgrouting 2.0.0 pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality. Advantages of the database routing approach are: * Data and attributes can be modified by many clients, like QGIS and uDig through JDBC, ODBC, or directly using Pl/pgSQL. The clients can either be PCs or mobile devices. * Data changes can be reflected instantaneously through the routing engine. There is no need for precalculation. * The "cost" parameter can be dynamically calculated through SQL and its value can come from multiple fields or tables. ok sthen@ 2014-12-16 21:34:35 +00:00			`CATEGORIES = geo databases`

			`HOMEPAGE = http://pgrouting.org/`

			`MAINTAINER = Landry Breuil <landry@openbsd.org>`

			`# GPLv2`
			`PERMIT_PACKAGE_CDROM= Yes`

sync WANTLIB 2016-07-09 09:09:08 +00:00			`WANTLIB += CGAL boost_system-mt boost_thread-mt gmp m pthread`
use COMPILER_LIBCXX where applicable 2017-07-16 19:18:47 +00:00			`WANTLIB += boost_atomic-mt boost_chrono-mt boost_date_time-mt ${COMPILER_LIBCXX}`
sync WANTLIB 2016-07-09 09:09:08 +00:00
WANT_CXX 2017-05-27 04:54:31 +00:00			`MODULES = databases/postgresql devel/cmake`
switch COMPILER from the old, confusing shortcuts to the more explicit format 2017-11-16 23:20:37 +00:00			`COMPILER = base-clang ports-gcc`
Import pgrouting 2.0.0 pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality. Advantages of the database routing approach are: * Data and attributes can be modified by many clients, like QGIS and uDig through JDBC, ODBC, or directly using Pl/pgSQL. The clients can either be PCs or mobile devices. * Data changes can be reflected instantaneously through the routing engine. There is no need for precalculation. * The "cost" parameter can be dynamically calculated through SQL and its value can come from multiple fields or tables. ok sthen@ 2014-12-16 21:34:35 +00:00
			`LIB_DEPENDS = math/cgal`
Enable the regress test like its done for postgis (prompted by zhuk@, thanks!) - fix RDEP while here, postgis is needed at runtime. 2014-12-19 21:16:55 +00:00			`RUN_DEPENDS = geo/postgis`
Import pgrouting 2.0.0 pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality. Advantages of the database routing approach are: * Data and attributes can be modified by many clients, like QGIS and uDig through JDBC, ODBC, or directly using Pl/pgSQL. The clients can either be PCs or mobile devices. * Data changes can be reflected instantaneously through the routing engine. There is no need for precalculation. * The "cost" parameter can be dynamically calculated through SQL and its value can come from multiple fields or tables. ok sthen@ 2014-12-16 21:34:35 +00:00			`BUILD_DEPENDS = databases/postgresql,-server`
Enable the regress test like its done for postgis (prompted by zhuk@, thanks!) - fix RDEP while here, postgis is needed at runtime. 2014-12-19 21:16:55 +00:00			`TEST_DEPENDS = ${BUILD_PKGPATH}`
Use new shiny postgresql.port.mk. Input for pgrouting part and okay for it from landry@ 2015-01-12 20:57:55 +00:00			`TEST_ENV = LD_PRELOAD=libpthread.so`
Update to pgrouting 2.5.2. Use a variable like in postgis to avoid big PLIST churn at each update. 2017-11-21 20:41:18 +00:00			`SUBST_VARS = V`
Use new shiny postgresql.port.mk. Input for pgrouting part and okay for it from landry@ 2015-01-12 20:57:55 +00:00			`MODPOSTGRESQL_TEST_CMD = \`
			`cd ${WRKSRC}; \`
Update to pgrouting 2.3.0. http://docs.pgrouting.org/2.3/en/doc/src/changelog/release_notes.html#changelog-2-3-0 2016-10-31 17:59:01 +00:00			`./tools/testers/algorithm-tester.pl`
Import pgrouting 2.0.0 pgRouting extends the PostGIS / PostgreSQL geospatial database to provide geospatial routing functionality. Advantages of the database routing approach are: * Data and attributes can be modified by many clients, like QGIS and uDig through JDBC, ODBC, or directly using Pl/pgSQL. The clients can either be PCs or mobile devices. * Data changes can be reflected instantaneously through the routing engine. There is no need for precalculation. * The "cost" parameter can be dynamically calculated through SQL and its value can come from multiple fields or tables. ok sthen@ 2014-12-16 21:34:35 +00:00
			`.include <bsd.port.mk>`