[mapserver-dev] cmake build support (UNCLASSIFIED)

[Alan Boudreault]

I'm in favor of cmake since the first time we talked about it. I can 
help for the migration.

Alan

On 13-03-18 09:36 AM, Smith, Michael ERDC-CRREL-NH wrote:
> 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
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>


-- 
Alan Boudreault
http://www.mapgears.com/