<div dir="ltr">On Wed, Jul 17, 2013 at 6:55 AM, Ryan Schmidt <span dir="ltr"><<a href="mailto:ryandesign@macports.org" target="_blank">ryandesign@macports.org</a>></span> wrote:<div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Jul 17, 2013, at 04:28, Michael Wimmer <<a href="mailto:wimmer.mike@gmail.com">wimmer.mike@gmail.com</a>> wrote:<br>>> If the build does not respect the compiler choice, that is a bug that should be fixed.<br>
><br>> thanks for your answer, I understand that this is how it should be done<br>
> in general. However, what I run into is a general problem, as this is a<br>
> python setuptools behavior: By default, they always want to use the<br>
> compiler that python itself has been compiled with (I assume to avoid<br>
> inconsistencies).<br>
<br>
</div>If that is how Python in MacPorts behaves, then I would call that a bug in Python in MacPorts that needs to be fixed. Ports should use the compiler indicated by configure.compiler. Anything else is wrong.<br></blockquote>
<div><br></div><div style>Letting (for forcing!) a language extension use a different compiler from the base language results in extensions that won't load in the base. (True of Python, Perl, and Tcl at minimum; also likely GHC.) You are correct in the general case but not in this particular special case, and the Python and Perl extension mechanisms force the compiler for very good reasons.</div>
<div><br></div></div>-- <br><div dir="ltr"><div>brandon s allbery kf8nh sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a> <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div>
<div>unix, openafs, kerberos, infrastructure, xmonad <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div>
</div></div>