[mapserver-dev] cmake build support

Daniel Morissette dmorissette at mapgears.com
Wed Mar 20 19:41:08 PDT 2013

Hi Thomas, and all,

I have no experience with cmake but I am supportive of the cmake idea as 
long as we can maintain compatibility with all platforms and build 
scenarios that used to be supported. i.e. it would be sad to find out 
that the switch to cmake made the life of some of our users miserable... 
I'm not saying that I have reasons to believe that it would be the case, 
just that the autoconf system has come to support several building 
scenarios over time and we will likely need to support most of them with 
cmake as well, hopefully that will just be easier.

And with respect to the "stable" C API, we are currently discussing a 
potential project with a client that would likely require C bindings and 
could possibly provide us with some funding to participate in a C API 
migration effort... so I'm positive about this as well (conditional to 
this project taking off of course).


On 13-03-17 12:33 PM, thomas bonfort wrote:
> 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
> - 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

Daniel Morissette
Provider of Professional MapServer Support since 2000

More information about the mapserver-dev mailing list