Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic compilation and linking on Windows #4

Open
johanseland opened this issue May 8, 2013 · 2 comments
Open

Dynamic compilation and linking on Windows #4

johanseland opened this issue May 8, 2013 · 2 comments

Comments

@johanseland
Copy link

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

@inducer
Copy link
Owner

inducer commented May 8, 2013

No, modepy does something entirely different--it's a helper for high-order methods. :)

@inducer
Copy link
Owner

inducer commented May 10, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants