On Wed, Aug 22, 2012 at 3:25 PM, Travis Oliphant <tra...@continuum.io> wrote: > > On Aug 22, 2012, at 3:59 AM, Ralf Gommers wrote: > > > > On Tue, Aug 21, 2012 at 12:51 AM, Travis Oliphant <tra...@continuum.io> > wrote: >> >> I'm actually not sure, why. I think the issue is making sure that the >> release manager can actually "build" NumPy without having to buy a >> particular compiler. > > > That would help, yes. MS Express doesn't work under Wine last time I checked > by the way. > > However, the issue is more than just one license. There's a large number of > packages that depend on numpy and provide binaries. If they can't make those > compatible with numpy ones, that's a problem. Users will first install numpy > 64-bit, and then later find out that part of the scientific Python stack > isn't available to them anymore. > > > > As far as I understand, you don't *have* to build all downstream > dependencies with the same compiler that NumPy was built with unless your > extension relies on the way C-functions pass structures on the stack (not > pointers to them, but structures as a whole) or if it relies on the > representation of FILE*. At one time all structures were passed as > pointers specifically for this reason. The FILE* situation is a problem, > but most extensions don't use NumPy C-API calls that have a FILE* argument.
It is much more pervasive than that, unfortunately. And for fortran, it is much worse, because if we build scipy or numpy with Intel Fortran, I think we pretty much force everyone to use intel fortran for *any* binary on top of them. David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
