Open MolotovCherry opened 10 months ago
I actually thought about that for a while (and I had implemented it even), but I decided not to implement it simply because you can't ship the whole repository to crates.io
(too big) and I wouldn't want the build to be reliable on GitHub.
An alternative to this could be a script that downloads pre-built binaries for every platform and puts them in the correct path. But I have to take time to make binary builds for every single platform.
I completely understand the reasons. I still think that having a ready to go build.rs
file in the docs at least with some steps would be really helpful (and thankfully, this build.rs won't mess with the one already in the crate on crates.io)
E.g.
libmem
repo to a subfolder in your project with git clone --recurse-submodules --remote-submodules <YourGitHubUrl>
build.rs
script in your project to build it. If you want, you can implement additional functionality to save/cache the generated libs and hardcode the path to them so they don't recompile all the timeOr you can go about it this other way with these other steps, and install it globally to make it easy on yourself later, with this other build script which is simple and hardcoded
(One bonus the former one has is when it comes to github actions builds, which can also be cached, though I should note that github actions will fail to build this unless you set CARGO_TARGET_DIR
to something like D:\target
, since cmake runs out of path space on the build otherwise)
(I got this building on github actions, and it's quite convenient)
By the way, thanks for your library and the hard work you put into it! It's really nice! 😄
I'm working on other projects right now, but I see that this is definitely something to worry about. I'll pin this issue so (hopefully) I don't forget. Thanks for your suggestion :+1:
About pre-built binaries, I've made a repo that creates them for multiple platforms (the script can be used standalone or via GitHub Actions to create GitHub Releases): https://github.com/nathan818fr/libmem-build Feel free to fork or use parts of this repo.
There is one difference regarding linux: it provide the static libraries independently (so it use liblibmem_partial.a instead of the one created by makebundle.sh). This makes the artifacts more similar between Windows and Linux.
PS: Thanks for libmem
@nathan818fr
That's impressive! We could definitely use that here :100:
For the static library, I think one might have linking issues with it. If I remember correctly, the linker does not link multiple static libraries together into a single one, so the third party dependencies will be left off. And that's what makebundle.sh
is supposed to solve (it generates a big binary though).
With that said, I will be taking a better look at the repo, and PRs are welcome if you wish to contribute directly
Having that implemented in the main repo will save a lot of time here, thanks for your efforts :+1:
Yes, with my way, all libraries must be linked to the target program. That's what I'm doing here on a project using libmem: https://github.com/nathan818fr/ts3-server-hook/blob/9ed27aaea3b4edb15fe9a984c0d5709d9e1f99b6/cmake/libmem-config.cmake
It's true that it's probably simpler to distribute just one big static binary (probably easier for users, etc.). In that case, would it be nice to do the same thing on Windows (so it would give a similar result between the different platforms with only: liblibmem.so|libmem.dll and liblibmen.a|libmem.lib)? I'll take a look.
Are you OK with the current artifact structure?
include/libmem/
- directory with libmem headerslib/
- directory with libmem dynamic and static librarieslicenses/
- directory containing all licenses (libmem and dependencies)GLIBC_VERSION.txt
|MUSL_VERSION.txt
|MSVC_VERSION.txt
|[...] - single-line text file providing essential version information for the platform (e.g. the glibc version used at compile-time generally indicates the minimum version required by the runtime - that's why I compile on debian buster, the oldoldstable)I will submit a PR soon.
@nathan818fr IIRC, MSVC is able to ship all the libraries into one without any additional steps, so that's why the makebundle.sh
script doesn't run for Windows.
As for the structure, I think it's pretty good. Everything important seems to be included :100:
Maybe I'm missing something, but when I build with MSVC I don't get all shipped into one library. I get:
And if I try to compile a demo that uses LM_HookCode
, it doesn't work without explicitly including the other libraries.
Edit: OP also link with all libraries:
Edit 2: It works well when also bundling libraries manually on Windows: https://github.com/nathan818fr/libmem/commit/d4314b5ec8f892644dd3f642e71d632994f37f2f
@nathan818fr That's interesting. I really thought MSVC resolved the linking problems for me, apparently not. Good to know. I'll try your manual bundling for Windows later :+1:
In Python, the setup.py
script will fetch a binary release from the GitHub if it has not found a libmem installation in the OS. The same could be done for Rust.
Now both Python and Rust dynamically fetch the library, avoiding annoyances from building and linking libmem. The only thing left to do is make this more friendly for C/C++ On Linux, it's pretty good already due to the CMakeLists thing that dynamically fetches and links libmem. But on Windows, most people will use Visual Studio projects, that's probably what should be aiming for Either way, a lot of progress on this field 💯
I just want to contribute here, (don't want to go through a PR rn), you can automate building the dependency in Rust using the
cmake
build dependency, and thisbuild.rs
. (Also, clonelibmem
repo and its submodules to a subfolder in your project)Feel free to take this code anyone. Specifically, it's for Windows and a static build. Enjoy 😄
Code
```rs use std::error::Error; use std::path::PathBuf; use winreg::enums::HKEY_LOCAL_MACHINE; use winreg::RegKey; pub fn get_windows_kits_dir() -> Result