openbsd-ports/geo/pgrouting/Makefile

# $OpenBSD: Makefile,v 1.11 2017/04/28 10:42:42 landry Exp $

COMMENT =	geospatial routing extension for PostgreSQL

GH_TAGNAME =	v2.4.1
GH_PROJECT =	pgrouting
GH_ACCOUNT =	pgRouting

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

MODULES =	databases/postgresql devel/cmake gcc4
MODGCC4_ARCHS =	*
MODGCC4_LANGS =	c c++

LIB_DEPENDS =	math/cgal
RUN_DEPENDS =	geo/postgis
BUILD_DEPENDS =	databases/postgresql,-server
TEST_DEPENDS =	${BUILD_PKGPATH}
TEST_ENV =	LD_PRELOAD=libpthread.so

MODPOSTGRESQL_TEST_CMD = \
	cd ${WRKSRC}; \
	./tools/testers/algorithm-tester.pl

.include <bsd.port.mk>
Update to pgrouting 2.4.1. 2017-04-28 10:42:42 +00:00			`# $OpenBSD: Makefile,v 1.11 2017/04/28 10:42:42 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.4.1. 2017-04-28 10:42:42 +00:00			`GH_TAGNAME = v2.4.1`
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			`GH_PROJECT = pgrouting`
			`GH_ACCOUNT = pgRouting`

			`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`
			`WANTLIB += boost_atomic-mt boost_chrono-mt boost_date_time-mt`

Update to pgrouting 2.1.0. Tested with grenoble data from mapzen metro extracts, imported with osm2pgrouting, and using pgRoutingLayer extension in QGIS. 2015-09-19 15:44:12 +00:00			`MODULES = databases/postgresql devel/cmake gcc4`
			`MODGCC4_ARCHS = *`
			`MODGCC4_LANGS = c c++`
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`
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
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>`