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

deno-gyp #1654

Closed
dsseng opened this issue Feb 2, 2019 · 10 comments
Closed

deno-gyp #1654

dsseng opened this issue Feb 2, 2019 · 10 comments

Comments

@dsseng
Copy link
Contributor

dsseng commented Feb 2, 2019

Idea: add something like node-gyp for native modules.

@kyranet
Copy link
Contributor

kyranet commented Feb 2, 2019

You mean GN, right? We don't use GYP here.

There was a discussion about native modules during September-November or so but turned out unconclusive, but I definitely would like this support, the question is: how?

@benjamingr
Copy link
Contributor

I personally think a big selling point is message-passing FFI like Ryan talked about in JSConf rather than having deno deal with the whole toolchain like Node has to

@ry
Copy link
Member

ry commented Feb 2, 2019

I'm open to suggestions. Native extensions are difficult and insecure. Maybe we can do something with WASM.

For the time being we have our arms full just making the basic modules work.

@kitsonk
Copy link
Contributor

kitsonk commented Feb 2, 2019

WASM would be ideal for some use cases, it certainly would be secure. Additional external bindings though would be a problem, but that is the security problem with native extensions.

@benjamingr
Copy link
Contributor

wasm sounds like an excellent extension point except for where additional system APIs are required.

@dsseng
Copy link
Contributor Author

dsseng commented Feb 3, 2019

@benjamingr ye, but my issue was especially for system apis such as OpenCL, CUDA, TensorFlow etc

@dsseng
Copy link
Contributor Author

dsseng commented Feb 3, 2019

@ry how soon #1325 will be done?

@bartlomieju
Copy link
Member

With #2385 in progress can we close this issue? It seems to be a duplicate of #296.

CC @ry

@ry
Copy link
Member

ry commented Sep 6, 2019

indeed - let's move the discussion to #296

@wenjoy
Copy link

wenjoy commented Jul 29, 2020

#654 is also related. Just want to link them together.

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

7 participants