[IPython-dev] trying to compile pyzmq

MinRK benjaminrk@gmail....
Thu Jun 9 19:42:28 CDT 2011


On Thu, Jun 9, 2011 at 16:35, Ilan Schnell <ischnell@enthought.com> wrote:

> Hello Group,
>
> it is true that EPD installs zmq.h (anf many other header file,
> other than the Python ones) in <sys.prefix>/include.  This way
> the headers are always on the include path, if you use
> distutils to compile C extensions.
>

Yes, it's definitely appropriate to install the headers there for
development. Their presence is not the problem.


>
> > EPD has installed zmq.h to
> > /Library/Frameworks/EPD64.framework/Versions/7.0/include, then?  If
> adding
> > locations to include_dirs explicitly does not take precedence over the
> > system defaults, then this is honestly a huge, critical bug in EPD
> itself,
> > but I'm not 100% what's responsible for EPD being inappropriately
> prepended
> > to the include path.
>
> distuils is responsible this, so it is not a hugh critical bug in EPD
> itself,
> although one could argue that it is a bug in distutils.  However, we don't
> want to change distutils default behavior in EPD.
>

I agree that you wouldn't want to change the behavior of distutils, but it
is not accurate that distutils is entirely responsible.

EPD's config/Makefile specifies  `-I<sysprefix>/include` dir in OPT, which
ends up in CFLAGS, which comes *before* any user-specified include dirs.

Python.org builds do not have any include dirs in this variable, and thus do
not have this problem (possibly for this reason).  The result is that EPD
includes sysprefix/include *twice* - in the highest priority position via
CFLAGS, and in the lowest priority position via normal channels.  The latter
doesn't cause any problems, but the former breaks user-specified include
paths.

If you
edit /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/Makefile
and remove the trailing '-I/Library...', from line 61 (starting `OPT=`) then
configuration will be properly respected.

Note that this does not remove the -I<sysprefix>/include from compilation
flags, it only removes the *duplicate* entry that placed it at the highest
priority inappropriately.

Since this is an issue that makes EPD behavior different from Python.org
installs in a build-breaking way, I think it can rightly be considered an
EPD bug, though it is distutils that pulls the EPD configuration into the
compilation commands.  However, it could also be considered a deliberate
feature that EPD prevents the use of multiple versions of compiled libraries
by overriding user preferences during compilation.

-MinRK



>
> > The dirty, hackish answer would be to remove (or rename) the zmq headers
> > installed by EPD, or install libzmq with a prefix of
> > '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the
> old
> > libzmq.  There shouldn't be any EPD code that requires the existence of
> the
> > zmq *headers*, but if they do similar horrible things with library paths,
> > then you will only get one step further, and need to remove/replace
> libzmq
> > in EPD entirely.
>
> removing the zeromq EPD package, which includes the headers is a good
> solution.
>
> - Ilan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-dev/attachments/20110609/378c62df/attachment.html 


More information about the IPython-dev mailing list