<br><br><div class="gmail_quote">On Thu, Jun 9, 2011 at 16:35, Ilan Schnell <span dir="ltr"><<a href="mailto:ischnell@enthought.com">ischnell@enthought.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello Group,<br>
<br>
it is true that EPD installs zmq.h (anf many other header file,<br>
other than the Python ones) in <sys.prefix>/include. This way<br>
the headers are always on the include path, if you use<br>
distutils to compile C extensions.<br></blockquote><div><br></div><div>Yes, it's definitely appropriate to install the headers there for development. Their presence is not the problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> EPD has installed zmq.h to<br>
> /Library/Frameworks/EPD64.framework/Versions/7.0/include, then? If adding<br>
> locations to include_dirs explicitly does not take precedence over the<br>
> system defaults, then this is honestly a huge, critical bug in EPD itself,<br>
> but I'm not 100% what's responsible for EPD being inappropriately prepended<br>
> to the include path.<br>
<br>
</div>distuils is responsible this, so it is not a hugh critical bug in EPD itself,<br>
although one could argue that it is a bug in distutils. However, we don't<br>
want to change distutils default behavior in EPD.<br></blockquote><div><br></div><div>I agree that you wouldn't want to change the behavior of distutils, but it is not accurate that distutils is entirely responsible.</div>
<div><br></div><div>EPD's config/Makefile specifies `-I<sysprefix>/include` dir in OPT, which ends up in CFLAGS, which comes *before* any user-specified include dirs.</div><div><br></div><div>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.</div>
<div><br></div><div>If you edit /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config/Makefile</div><div>and remove the trailing '-I/Library...', from line 61 (starting `OPT=`) then configuration will be properly respected.</div>
<div><br></div><div>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.</div><div><br></div>
<div>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.</div>
<div><br></div><div>-MinRK</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> The dirty, hackish answer would be to remove (or rename) the zmq headers<br>
> installed by EPD, or install libzmq with a prefix of<br>
> '/Library/Frameworks/EPD64.framework/Versions/7.0', thus clobbering the old<br>
> libzmq. There shouldn't be any EPD code that requires the existence of the<br>
> zmq *headers*, but if they do similar horrible things with library paths,<br>
> then you will only get one step further, and need to remove/replace libzmq<br>
> in EPD entirely.<br>
<br>
</div>removing the zeromq EPD package, which includes the headers is a good solution.<br>
<font color="#888888"><br>
- Ilan<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br>