[mapguide-internals] Our internal copy of SWIG

[Jackie Ng]

Hi All,

This is a heads-up discussion I want to kick-start about a future problem
that we have up to 2 years to address.

The problem concerns the MapGuide API wrapper for PHP and our internal copy
of SWIG used to generate it.

For those who may not know, PHP 5.6 (that is bundled with the most recent
3.1 release) becomes end of life on 31 December 2018. We want to generally
keep external components like Apache/PHP/Tomcat up to date where possible as
we don't want to ship MapGuide/AIMS and bundle something that is marked end
of life by the respective vendor, especially for web-facing components like
PHP.

PHP 5.6 is the last in the 5.x series. The next version after that is the
7.x series. Unfortunately, it is not possible for us to upgrade to PHP 7.x
at the moment due to breaking changes in the zend extension API that is
incompatible with the C/C++ code that our internal copy of SWIG currently
generates. The C/C++ code that our copy of SWIG generates for our PHP
wrapper does not compile against the PHP 7.x zend extension APIs.

The good news is that support for PHP 7.x recently landed in SWIG
(https://github.com/swig/swig/issues/571). 

Thus I want to use this discussion to explore the feasibility/possibility of
generating our MapGuide API wrappers with a vanilla, un-modified version of
SWIG.

The unknown is whether we can adopt this version of SWIG that will have PHP7
support due to:

 1. The unknown audit trail of source modifications made to our internal
copy of SWIG. In particular, what changes were made to the internal copy
before the MapGuide source repository was migrated to Trac (I think it was
called CollabNet?). Is it possible for us to generate the PHP wrapper with
vanilla SWIG or is the volume of changes to our internal copy of SWIG
divergent enough that it is not possible to generate MapGuide API wrappers
with vanilla SWIG due to customizations that cannot be replicated with SWIG
typemaps and other built-in customization features?

 2. License changes to SWIG (GPL3) that prevent us from storing an internal
copy as we currently do. We'd most likely have to amend our build
system/procedure to assume an externally acquired copy of SWIG to already be
installed.

 3. This will most likely have flow-on effects for the .net and Java
wrappers too as they are also generated by SWIG. We could retain our
internal copy of SWIG, but only use it for generating the .net and Java
wrappers and leave the PHP7 one for , or we bite the bullet and get these
working with vanilla SWIG as well.

As a majority of our current user/web facing MapGuide applications and admin
tools are PHP-based, this is a discussion I seriously believe we should be
having. The sooner we have a solid plan of action to deal with the
end-of-life of the 5.6 series of PHP in under 2 years time, the better.

- Jackie



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Our-internal-copy-of-SWIG-tp5302810.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.