<div dir="ltr">On Sat, Feb 18, 2012 at 15:15, Eugene Crosser <span dir="ltr"><<a href="mailto:crosser@average.org">crosser@average.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think it would be a right thing to provide the author of an external module<br>
with "baseline" C environment by default, compatible with the environment under<br>
which the modules bundled with the compiler where built. And on top of that,<br>
allow them to use autoconf/whatever else to deviate from that if they need to.</blockquote><div><br></div><div>Agreed. There's a reason that languages with lots of experience with extensions (e.g. Perl, Python) make all the details of the environment the runtime was built under available to extensions/native code modules; you might be running a binary distribution on a system that is compatible with but not natively the same as the runtime's build environment, so using autoconf-type stuff to determine the native environment will lead to the extension having an inefficient, or at worst subtly (or not so subtly, as with 32 vs. 64 bit issues) incompatible, link to the runtime. You *really* don't want the runtime to be marshaling 32-bit values based on how it was built, but the module using autoconf to determine that the native value size is 64 bits and treating the marshaled value as such, or vice versa.</div>
</div><div><br></div><div>(In fact, just based on its name, I would have assumed that the point of HsFFI.h is to insure hsc2hs-ed (that is, FFI-using) modules get the types right, so making hsc2hs not use HsFFI.h makes little sense on its face.)</div>
<div><br></div>-- <br>brandon s allbery <a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a><br>wandering unix systems administrator (available) (412) 475-9364 vm/sms<br>
<br>
</div>