[mapserver-dev] cmake build support

[Jeff McKenna]

Hi Thomas,

As your wrote this email, I was/am deep into Apache build process on
Windows (starts with cmake).

I see benefits of both (makefiles vs cmake).

Personally I am for whatever works (currently makefiles for me).
Switching over for me would be substantial investment of time and
effort, but, I agree, for new users cmake is wonderful.

Not sure the point of my email, other than to give my thoughts.

-jeff



On 2013-03-17 1: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
> -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"
> 
>