rivet is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (Repository path '/hepforge/hg/rivet/public/rivet' does not exist.). Look in the Trac log for more information.

Opened 11 years ago

Last modified 11 years ago

#228 assigned defect

#include <Python.h> becomes #include <python2.5/Python.h> for OS X

Reported by: jmonk Owned by: jmonk
Priority: major Milestone:
Component: Steering Version:
Keywords: Cc: Andy Buckley, hoeth, Frank Siegert

Description

The system python libraries on OS X seem to use some fancy framework setup in /System/Library/Frameworks/Python?.framework/Versions/2.5/include/python2.5/. I think the point of the framework bundle structure is to allow you to switch versions with ease, so it would seem to make sense that it forces you to specify a version. Since you can swap the framework without recompiling the dependencies it can't rely on the current version.

Googling around this a bit it seems like even on Linux some people use #include <python/Python.h>. I guess the Rivet build system already adds places like /usr/local/include/python - maybe it shouldn't?

Change History (4)

comment:1 Changed 11 years ago by Andy Buckley

Cc: hoeth Frank Siegert added

You lot and your bloody Macs ;)

The Python-finding at the moment is purely based on the m4 macros at http://autoconf-archive.cryp.to/macros-by-category.html#PYTHON

We are using the older one, ac_python_devel, but it definitely has deficiencies: importantly it provides no way for the user to steer the failure behaviour. Before trying any custom hacking, we should probably try out the newer az_python macro ("New and revised Python support.") Can you take a look at that and see if it is any more Mac-friendly?

comment:2 Changed 11 years ago by Andy Buckley

Owner: changed from Andy Buckley to jmonk

The docs of the az_python macro explicitly mention the Mac OS X difference in how Python works from a developer point of view, so I think this is the way to go. As the person in the best situation to know whether it is having the desired effect, I nominate James as ticket owner ;)

comment:3 Changed 11 years ago by jmonk

The swig.mx macro seems to depend on the old style python.m4 to define AC_PYTHON_DEVEL and friends. It doesn't seem like there's a newer swig macro, so I might have to update that myself.

comment:4 Changed 11 years ago by jmonk

Status: newassigned

The newer python.m4 (plus AC_PYTHON_DEVEL from the older one) seems to work things out correctly. A couple of differences - ENABLE_PYRIVET has become PYTHON_USE and the configure switch is now --enable/disable-python (disabled by default). It doesn't build the rivet.py module unless enabled, but obviously the only way I can be sure it works without any python is to test it on a machine with an old version.

I also don't have commit rights to the autotools macros area on hepforge, so I can't commit the change!

Note: See TracTickets for help on using tickets.