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

Is there a better way to add cpp code? #213

Open
frank-pian opened this issue Feb 17, 2023 · 2 comments
Open

Is there a better way to add cpp code? #213

frank-pian opened this issue Feb 17, 2023 · 2 comments

Comments

@frank-pian
Copy link

Adding cpp code to the yml file looks fine.But it's inconvenient when there is a lot of code.
Can I specify that a list of cpp files be included for compilation?

@donalffons
Copy link
Owner

donalffons commented Mar 5, 2023

I've been thinking about this problem for a while and what I've come up with is implemented in another project called libclangjs, here. Libclangjs adds JavaScript / WASM bindings to llvm's libclang (similar to how OCJS adds JavaScript / WASM bindings to OCCT - but much simpler). There is a fairly minimal test and some docs that explain how it works. In summary:

  • The bindings and relevant headers are published as a CMake package, that can be added via CMake's find_package call to your custom CMake project (which builds an "executable", i.e. the .js and .wasm files, you want to use in your JS project).
  • This CMake package is published via NPM. That might be a bit unusual, but I think it's an easy way of publishing that package, which should integrate nicely with commonly used JS development tools. This should also work nicely with a monorepo layout, where the "custom build" of OCJS is just another package that can be installed by other packages inside that repo.
  • C/C++ code can then be written "like usual" in any other CMake-based project.

I believe this is much cleaner and lightweight than the current solution of adding c++ code to a yaml file and starting a huge Docker container for each compilation. If you have any thoughts / opinions on this, please let me know.

PS: This ignores the fact that the custom build yaml-files also specify which bindings should be included. This would be a separate issue under this proposal.

@frank-pian
Copy link
Author

I've been thinking about this problem for a while and what I've come up with is implemented in another project called libclangjs, here. Libclangjs adds JavaScript / WASM bindings to llvm's libclang (similar to how OCJS adds JavaScript / WASM bindings to OCCT - but much simpler). There is a fairly minimal test and some docs that explain how it works. In summary:

* The bindings and relevant headers are published as a CMake package, that can be added via CMake's [`find_package`](https://github.com/donalffons/libclangjs/blob/5af1087a3dd29f05b03ca38360d7a07d17c73277/tests/test-cmake/CMakeLists.txt#L7) call to your custom CMake project (which builds an "executable", i.e. the `.js` and `.wasm` files, you want to use in your JS project).

* This CMake package is published via NPM. That might be a bit unusual, but I think it's an easy way of publishing that package, which should integrate nicely with commonly used JS development tools. This should also work nicely with a monorepo layout, where the "custom build" of OCJS is just another package that can be installed by other packages inside that repo.

* C/C++ code can then be written "like usual" in any other CMake-based project.

I believe this is much cleaner and lightweight than the current solution of adding c++ code to a yaml file and starting a huge Docker container for each compilation. If you have any thoughts / opinions on this, please let me know.

PS: This ignores the fact that the custom build yaml-files also specify which bindings should be included. This would be a separate issue under this proposal.

It looks great ! If there are any examples, I would be happy to test.

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