>> > Now that you provide an installer for Atlas, it may become the same
> > problem as MKL, can't it ?
>> It is exactly the same problem, yes. Right now, my installer does not
> modify the environment at all (like MKL or ACML, actually), and you have
> to do it manually (add PATH, or put in system32).
OK ;)
> > Yes, they will complain to you for sure, but I can't see where dynamic
> > libraries can become a problem :
> > - are they numpy dlls ? is so there is a problem, I agree with you
>>> numpy 'dll' (they are technically dll, but are named .pyd on recent
> version of windows) are mandatory, and is not a problem: it is handled
> by python (whose import mechanism knows how to import dll not in the
> path env var).
Yes, that works as long as there are no "real" dll that were built at the
same time.
> - are they external dlls ? If so, the installer must have set up
> > everything so that everything works, but this is where people bark at
> > the wrong people : the users of the dll and not the installers.
>> Well, neither ACML or MKL does it, at least the versions I looked into.
> You have to launch a special cmd.exe (like for VS2005) which import the
> variables.
>
That's almost stupid... I understand now what you meant :|
Matthieu
--
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080219/af27243a/attachment-0001.html