-
Notifications
You must be signed in to change notification settings - Fork 1
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
Figure out dependency management solution #1
Comments
N.B. I'm currently vendoring Sol in case I need to apply patches, but I'm currently undecided whether I want to continue using Sol or just write the bindings myself. |
My 2c is that if we do it ourselves it might be easier to shape the API and its one less dependency to go wrong. We can also tailor it to work with ref-returning methods, unlike Sol2. |
Yeah. It's just a lot of code, and Sol affords us some level of "rapid" development and prototyping. Plus, it's intentionally designed as a somewhat leaky abstraction, so it should be fairly easy to "break out" and use the raw Lua API if we need anything fancy. |
Update: Due to issues with how Conan distributes Lua and Sol, I've decided for now to vendor both of these. However, I have designed it such that we can disable the vendoring of Lua and Sol at a later point, using the following options:
Currently, the behaviour is roughly as such:
|
I've yeeted Sol and now we always vendor Lua. You can specify |
With the removal of conan from NovelRT, is the title of this issue still accurate? |
Conan is dead across all our projects. We should probably update this ticket to reflect the new approach, once we have trialled it in NovelRT fully and worked out the issues with it. |
Right now, the build script requires that Lua be installed somewhere accessible to CMake; it does not use any sort of package manager like Conan.We probably should do that.We should probably figure out a long-term dependency management solution.
The text was updated successfully, but these errors were encountered: