Our internal copy of SWIG

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

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