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

Figure out dependency management solution #1

Open
FiniteReality opened this issue Jan 8, 2022 · 7 comments
Open

Figure out dependency management solution #1

FiniteReality opened this issue Jan 8, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@FiniteReality
Copy link
Contributor

FiniteReality commented Jan 8, 2022

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.

@FiniteReality FiniteReality added the enhancement New feature or request label Jan 8, 2022
@FiniteReality
Copy link
Contributor Author

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.

@RubyNova
Copy link
Member

RubyNova commented Jan 8, 2022

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.

@FiniteReality
Copy link
Contributor Author

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.

@FiniteReality
Copy link
Contributor Author

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:

  • FABULIST_THIRDPARTY: turns on/off all vendored third-party libraries
  • FABULIST_THIRDPARTY_SOL: turns on/off vendoring for Sol (set to OFF if FABULIST_THIRDPARTY is OFF)
  • FABULIST_THIRDPARTY_LUA: turns on/off vendoring for Lua (set to OFF if FABULIST_THIRDPARTY is OFF)

Currently, the behaviour is roughly as such:

FABULIST_THIRDPARTY_SOL FABULIST_THIRDPARTY_LUA Behaviour
OFF OFF No third party libraries used. Build system will assume presence of sol2 target.
OFF ON Known to be broken: Build system will assume presence of sol2 target and then throw an error.
ON ON Build system will use vendored third-party libraries. sol2 target depends on lua target.

@FiniteReality
Copy link
Contributor Author

I've yeeted Sol and now we always vendor Lua. You can specify FABULIST_LUA_VERSION to switch between 5.1, 5.2, 5.3 and 5.4.

@Pheubel
Copy link

Pheubel commented Sep 7, 2022

With the removal of conan from NovelRT, is the title of this issue still accurate?

@RubyNova
Copy link
Member

RubyNova commented Sep 7, 2022

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.

@FiniteReality FiniteReality changed the title Use Conan to manage dependencies Figure out dependency management solution Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants