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

Build dependecy handling with hard copies #26

Open
SebastianMeinberger opened this issue Mar 25, 2024 · 0 comments
Open

Build dependecy handling with hard copies #26

SebastianMeinberger opened this issue Mar 25, 2024 · 0 comments

Comments

@SebastianMeinberger
Copy link

Build dependencies are currently handled inconsistently.
Most are included as a submodule (minhook, asio, wswrap, websocketpp and apclientpp) but some are simple hard copies (valijson, nlohmann and openSSL is even hard copied twice https://github.com/Marechal-L/Dark-Souls-III-Archipelago-client/tree/main/archipelago-client/dep/openssl and https://github.com/Marechal-L/Dark-Souls-III-Archipelago-client/tree/main/archipelago-client/subprojects/openssl).
Hard copies are always a bit difficult in terms of licences, bloat up project size and make versioning and updating harder.
In my opinion, they should be removed.

Additionally, most inclusions of subprojects are unnecessary in my opinion (But I am admittedly pretty biased since I'm not a big fan of submodules :D ).
Except for wswrap and apclientpp, all build dependencies are very common C++ dependencies that are available through most generic C++ dependencie solution.
In my opinion, vcpkg would be a good way to handle them.
Vcpkg was made for your build system, Visual Studio, but is also compatible with most other build systems.
It is pretty easy to handle and takes care of nearly all headaches that build dependency stuff can cause.

I'm currently doing a pretty major refactor of this client and most of the current changes are probably not of interest to you since they only concern porting the build process to cmake and changing the runtime deps to mingw-64 instead of Windows, but I made a branch where I cherry-picked the parts concerning the dependency handling with vcpkg.
You would then have to adjust the VS Project to use vcpkg and maybe change some include directives (I can't make any promises that there wont be other problems, I never used VS, but considering vcpkg is made by Microsoft for VS, it should work relatively smoothly).
I'll make a pull request for that branch, but feel free to just close that request again if you don't want to use vcpkg.

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

1 participant