You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Moving discussion of inducer/pycuda#25 over here, where it should have been in the first place.
The docs righly state that dynamic compilation and linking is now working on Windows. Is there any plans to remedy this situation?
I have had a small peek on how the toolchains are being set up in CodePy, and I guess it should be possible to add MSVC to it as well. Continuing on this path, will one not potentially end up with having duplicated a cross-platform build system in Python. Would it not be better to utilize Bjam? It should be available on any system using Boost anyway to abstract away the platform independent anyways?
(On CUDA systems nvcc also does the build platform abstraction, so adding a third one
seems a bit excessive, CMake is of course another alternative to cross platform building, which also can call NVCC.)
Or is this new modePy-stuff going to replace CodePy
The text was updated successfully, but these errors were encountered:
I don't have any immediate plans to add Windows support to CodePy. (I find that doing JIT/code generation using (Py)OpenCL is more robust and easier.) I'd be happy to take a patch though.
As far as using bjam is concerned, I'm not really a fan of the idea. First of all, remote-manipulating bjam into doing the right thing is hard, too. First you have to find the executable. (Is it on the path? What if the user just installed dev packages with headers from a Linux distribution?) Then you have to write out a Jamfile. Then call bjam. Then clean up the mess it made. All while providing a relatively fine-grained compile-this, link that API along with caching... Also I feel that the use case is different. bjam's point is to build gigantic projects with many thousands of files. CodePy's point is to compile many small things, each of which ends up being a module that gets linked into the interpreter.
Moving discussion of inducer/pycuda#25 over here, where it should have been in the first place.
The docs righly state that dynamic compilation and linking is now working on Windows. Is there any plans to remedy this situation?
I have had a small peek on how the toolchains are being set up in CodePy, and I guess it should be possible to add MSVC to it as well. Continuing on this path, will one not potentially end up with having duplicated a cross-platform build system in Python. Would it not be better to utilize Bjam? It should be available on any system using Boost anyway to abstract away the platform independent anyways?
(On CUDA systems nvcc also does the build platform abstraction, so adding a third one
seems a bit excessive, CMake is of course another alternative to cross platform building, which also can call NVCC.)
Or is this new modePy-stuff going to replace CodePy
The text was updated successfully, but these errors were encountered: