I agree that it's a bit silly the number of places headers can end up.
If you look at how numpy does it, they keep their headers inside the
numpy install (by specifying them as data files, perhaps?), which
gives them control over their location, rather than entrusting headers
to the install program to install wherever it thinks headers should
go.

-MinRK

On Thu, Apr 1, 2010 at 21:27, Andreas Klöckner <li...@informa.tiker.net> wrote:
> On Donnerstag 01 April 2010, MinRK wrote:
>> The `installed_path' variable in `_find_pycuda_include_path' in
>> pycuda/compiler.py appears to be incorrect, or at least not
>> sufficiently general, because it does not find the install location on
>> my machines (OSX 10.6/Python 2.6.1 and Ubuntu 9.10/Python 2.6.4).
>>
>> $> python setup.py install --prefix=$HOME/usr/local
>>
>> installs pycuda to ~/usr/local/lib/python2.6/site-packages/pycuda
>> and the pycuda headers to ~/usr/local/include
>>
>> but the installed_path variable is defined with:
>>
>>     installed_path = join(pathname, "..", "include", "pycuda")
>>
>> which points to:
>> ~/usr/local/lib/python2.6/site-packages/include/pycuda, which is
>> incorrect.
>> adding three more ".." fixes the location:
>>
>>     installed_path = join(pathname, "..", "..", "..", "..", "include",
>>  "pycuda")
>>
>> and everything works once I add that patch.
>
> First of all, thanks for reporting this. I've added your patch to git.
> But really--this must be some sick joke, right? Currently PyCUDA looks
> in no fewer than *seven* places (on Linux) to figure out where its
> headers got installed.  I hope Tarek (Ziadé) gets done cleaning up
> distutils rather sooner than later... or is this all the distributors'
> doing?
>
> Andreas
>

_______________________________________________
PyCUDA mailing list
pyc...@host304.hostmonster.com
http://host304.hostmonster.com/mailman/listinfo/pycuda_tiker.net

Reply via email to