[mapserver-dev] cmake build support (UNCLASSIFIED)

Mon Mar 18 06:36:22 PDT 2013

Classification: UNCLASSIFIED
Caveats: NONE

I'm very much in favor of a cmake build. I find cmake works quite well for cross platform builds as I build on OSX, linux, Windows and Solaris Sparc. I should be able to provide testing and feedback on all these platforms.

Mike

Michael Smith
Remote Sensing/GIS Center
US Army Corps of Engineers

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
Sent: Sunday, March 17, 2013 12:33 PM
To: MapServer Dev Mailing List
Subject: [mapserver-dev] cmake build support

Hi devs,

This is a subject I would like to work on more thoroughly during the
code sprint, but might also interest some of those who won't make it
to Boston...

First, for a bit of context, I think it could be very useful if
mapserver were to export a "cleaner" and "stable" C api that could be
installed system-wide for usage by third party applications. Ideally,
we could split this public API into libmapserver and libmapfile APIs,
so that thirdparty tools could create and manipulate mapfiles without
a dependency on the whole mapserver dependencies, but that would
probably be a longer term goal.

This would be needed for a number of reasons:
- in a short term, this would allow mapcache do be cleanly packaged
independently, with the support for native mapserver rendering
- in a longer term
  - allow third party tools to read and manipulate mapfiles through
well defined and stable API. This would include TinyOWS for setting up
WFS-T services for an existing mapfile, or a tighter integration with
QGIS to easily export created projects to a mapserver wms server.
  - (ideally) simplify and stabilize the mapscript APIs by
centralizing in a single place what can or cannot be modified

While all this isn't tightly related to the original subject, I have
started working on migrating our build system from autotools to cmake.
The major changes from our current autoconf setup are:

- The logic in configure.in is getting unwieldy. Aside from it being
tough to maintain, there's a lot of cruft in there that was only
useful for very outdated versions of our dependencies.
- Cmake is supposed to be multi-platform, which would cut down on the
need for maintaining separate windows build scripts. Without *any*
experience on developing on windows, I was able to create
configurations for mingw and vc++ from scratch
- The rewrite was the occasion to clean up our configuration logic, by
using a mapserver-config.h file containing activated features instead
of needing to pass them to the compiler (our -DUSE_FOOBAR
-DNEED_STRFOOBAR flags)
- you get purty colored output ;)

Feedback would be greatly appreciated with regards to these changes,
along with some testing on a diversity of platforms. To try it out:

- git remote add tbonfort git://github.com/tbonfort/mapserver.git
- git fetch tbonfort
- git checkout --track tbonfort/cmake
- mkdir build && cd build
- cmake ..
- make

cuurently implemented options are:

option(WITH_PROJ "Choose if reprojection support should be built in" ON)
option(WITH_SOS "Enable SOS Server support (requires PROJ and libxml2
support)" OFF)
option(WITH_WMS "Enable WMS Server support (requires proj support)" ON)
option(WITH_GD "Choose if GD support should be built in" OFF)
option(WITH_FRIBIDI "Choose if FriBidi glyph shaping support should be
built in (usefull for left-to-right languages)" ON)
option(WITH_ICONV "Choose if Iconv Internationalization support should
be built in" ON)
option(WITH_CAIRO "Choose if CAIRO  rendering support should be built
in (required for SVG and PDF output)" ON)
option(WITH_MYSQL "Choose if MYSQL joining support should be built in" OFF)
option(WITH_FCGI "Choose if FastCGI support should be built in" ON)
option(WITH_GEOS "Choose if GEOS geometry operations support should be
built in" ON)
option(WITH_POSTGIS "Choose if Postgis input support should be built in" ON)
option(WITH_GDAL "Choose if GDAL input raster support should be built in" ON)
option(WITH_OGR "Choose if OGR/GDAL input vector support should be built in" ON)
option(WITH_CLIENT_WMS "Enable Client WMS Layer support (requires CURL
and GDAL support)" OFF)
option(WITH_CLIENT_WFS "Enable Client WMS Layer support (requires CURL
and OGR support)" OFF)
option(WITH_WFS "Enable WFS Server support (requires PROJ and OGR support)" ON)
option(WITH_WCS "Enable WCS Server support (requires PROJ and GDAL support)" ON)
option(WITH_LIBXML2 "Choose if libxml2 support should be built in
(used for sos, wcs 1.1,2.0 and wfs 1.1)" ON)
option(WITH_THREADS "Choose if a thread-safe version of libmapserver
should be built (only recommended for some mapscripts)" OFF)
option(WITH_GIF "Enable GIF support (for PIXMAP loading)" ON)
(note that other options aren't yet implemented, notably oracle, sde,
mssql, exempi, etc...)

for mapscript:
option(WITH_PYTHON "Enable Python mapscript support" ON)
option(WITH_PHP "Enable PHP mapscript support" ON)

for devs wanting to play with the lexer/parser:
option(WITH_FLEX_BISON "Regenerate parser" OFF)

These options can be activated with "cmake -DWITH_FOO=1/0 ..". Failed
dependencies and resolution /should/ be pretty verbose and
explanatory. Non-standard dependency locations can be supplied with
-DCMAKE_PREFIX_PATH="/path/to/dep1;/path/to/dep2"

All the best,
thomas
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev

Classification: UNCLASSIFIED
Caveats: NONE