py-matplotlib: pre-C99 compatibility patch

[ccorn]

On darwin9-powerpc, building py27-matplotlib@2.1.0_0+cairo+ghostscript+gtk2+latex+qt4 failed with a GCC error message complaining about a for-scope declaration in src/_macosx.m.

I have extended the existing files/patch-src-macosx.m.diff with one more hunk fixing that. As a result, py27-matplotlib builds with gcc-4.2.

[ccorn]

patch to be applied with -p0 in port dir py-matplotlib

[udbraumann]

Your proposed patch looks likes this and might be not valid:

diff --git a/python/py-matplotlib/files/patch-src-macosx.m.diff b/python/py-matplotlib/files/patch-src-macosx.m.diff
index 18dea4aa13..2b68c7f79f 100644
--- a/python/py-matplotlib/files/patch-src-macosx.m.diff
+++ b/python/py-matplotlib/files/patch-src-macosx.m.diff
@@ -1,5 +1,5 @@
---- src/_macosx.m.orig	2015-11-29 10:44:55.000000000 -0700
-+++ src/_macosx.m	2015-11-29 11:02:16.000000000 -0700
+--- src/_macosx.m.orig	2017-10-03 08:50:44.000000000 +0200
++++ src/_macosx.m	2017-10-10 12:40:29.000000000 +0200
 @@ -1,5 +1,8 @@
  #include <Cocoa/Cocoa.h>
  #include <ApplicationServices/ApplicationServices.h>
@@ -8,4 +8,14 @@
 +#endif
  #include <sys/socket.h>
  #include <Python.h>
- #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION
+ 
+@@ -1319,7 +1322,8 @@ NavigationToolbar_get_active (Navigation
+     }
+     Py_ssize_t list_index = 0;
+     PyObject* list = PyList_New(m);
+-    for (size_t state_index = 0; state_index < n; state_index++)
++    size_t state_index;
++    for (state_index = 0; state_index < n; state_index++)
+     {
+         if(states[state_index]==1)
+         {

[udbraumann]

Instead of patching the code I propose to add the -std=c99 switch to the C-compiler calls.

[ccorn]

Replying to udbraumann:

Your proposed patch looks likes this and might be not valid:

It is valid; the previous version applied with fuzz 1, the new version applies cleanly.

Replying to udbraumann:

Instead of patching the code I propose to add the -std=c99 switch to the C-compiler calls.

I agree, but configure.cflags-append does not do the trick. The following alternative works, maybe you find something more elegant:

diff --git a/python/py-matplotlib/Portfile b/python/py-matplotlib/Portfile
index 026846a53c..315073ebb8 100644
--- a/python/py-matplotlib/Portfile
+++ b/python/py-matplotlib/Portfile
@@ -68,6 +68,9 @@ if {${name} ne ${subport}} {
     # build fails with gcc-4.0 on Leopard, use gcc-4.2 (#37069)
     compiler.blacklist gcc-4.0
 
+    # Using some C99 constructs
+    build.cmd CFLAGS=\"\$CFLAGS -std=c99\" && ${build.cmd}
+
     post-destroot {
         if {${name} ne ${subport}} {
             xinstall -m 755 -d ${destroot}${prefix}/share/doc/${subport} \

The downside of this approach is that it generates C++ warnings:

cc1plus: warning: command line option "-std=c99" is valid for C/ObjC but not for C++

[udbraumann]

Replying to ccorn:

The downside of this approach is that it generates C++ warnings:

cc1plus: warning: command line option "-std=c99" is valid for C/ObjC but not for C++

That can happen if C and C++ code is being mixed, we should not care too much about this. I hope this Portfile change proposition is being adopted, at least for systems which come with gcc-4.2 as standard XCode-provided compiler.

[seanfarley (Sean Farley)]

I agree that the -std=c99 is a bit less fragile. It seems that configure.cflags should be passed to build.cmd all the time and that it's a bug currently.

[ccorn]

Replying to seanfarley:

It seems that configure.cflags should be passed to build.cmd all the time and that it's a bug currently.

Looking at the portgroup python-1.0.tcl I agree with that sentiment. The only reason CFLAGS etc are in the build.env at all is due to the default python.add_archflags yes, and the corresponding code sets CFLAGS only to the archflags. By overwriting, not by appending. Thus no optflags are passed to setup.py ever. But matplotlib's setup.py prepends its own flags nevertheless: I find -DNDEBUG -g -fwrapv -O3 -Wall in the log. Perhaps the portgroup designer trusts setup.py to do the right thing more often than generic MacPorts CFLAGS could.