<br><br><div class="gmail_quote">On Thu, Jun 9, 2011 at 16:35, Ilan Schnell <span dir="ltr">&lt;<a href="mailto:ischnell@enthought.com">ischnell@enthought.com</a>&gt;</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 &lt;sys.prefix&gt;/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&#39;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>
&gt; EPD has installed zmq.h to<br>
&gt; /Library/Frameworks/EPD64.framework/Versions/7.0/include, then?  If adding<br>
&gt; locations to include_dirs explicitly does not take precedence over the<br>
&gt; system defaults, then this is honestly a huge, critical bug in EPD itself,<br>
&gt; but I&#39;m not 100% what&#39;s responsible for EPD being inappropriately prepended<br>
&gt; 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&#39;t<br>
want to change distutils default behavior in EPD.<br></blockquote><div><br></div><div>I agree that you wouldn&#39;t want to change the behavior of distutils, but it is not accurate that distutils is entirely responsible.</div>

<div><br></div><div>EPD&#39;s config/Makefile specifies  `-I&lt;sysprefix&gt;/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&#39;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 &#39;-I/Library...&#39;, from line 61 (starting `OPT=`) then configuration will be properly respected.</div>

<div><br></div><div>Note that this does not remove the -I&lt;sysprefix&gt;/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>
&gt; The dirty, hackish answer would be to remove (or rename) the zmq headers<br>
&gt; installed by EPD, or install libzmq with a prefix of<br>
&gt; &#39;/Library/Frameworks/EPD64.framework/Versions/7.0&#39;, thus clobbering the old<br>
&gt; libzmq.  There shouldn&#39;t be any EPD code that requires the existence of the<br>
&gt; zmq *headers*, but if they do similar horrible things with library paths,<br>
&gt; then you will only get one step further, and need to remove/replace libzmq<br>
&gt; 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>