Include -sys crate for c lib without using git submodule

I don't like the idea of using git submodules in a cargo build as suggested here -How to make a -sys crate? - #4 by juleskers. I would rather have a single dependency tool to teach/learn for our projects. I'd like to be able to use 'normal' cargo mechanism to retrieve/track c library dependency that is in github with for example

klusolve = {git=""}

How can I build and install the c lib from my local cargo git repo?

Thanks in advance.

You can't include a non-cargo project as a cargo dependency. It you really need to avoid using submodules you can copy the files directly into your repo, but that makes keeping them up to date annoying.

Submodules are probably worth learning about anyway, as they're used in a lot of git repos


Thanks for the @-mention!

There is no "single tool to learn" when dealing with C code, because there is no such thing as a "standard" C project. Every project does it slightly differently.
For this reason, cargo doesn't have any standard functionality for it (also because the cargo team is has been under-staffed for years now, they need a couple extra volunteers/colleagues even for their current workload).

If you don't want to learn submodules, cargo won't care. Cargo treats a git-submodule exactly the same as a good ol' manual Ctrl+C, Ctrl+V copy. (in fact, they're identical on the filesystem, all the magic is in the .git subfolder).

The only person who cares about submodule-vs-ctrlC is future-You, when the time comes to upgrade your C-dependency from version X to vX+1.
I learned this annoying lesson the hard way, so I hope to save people the trouble with my advice :innocent:

With a "manual" copy, you'll have to figure out all the diffing yourself and do a replace-all update commit.
Tracking which old commit exactly you had becomes a matter of manual note-keeping in textfiles.

With git submodules, git itself remembers the commits of the child-repo, so the process becomes:

#go into the submodule dir
cd vendor/my-dep/

#get latest version
git pull --ff-only

# go back "up" to main project
cd ../.. 

git add vendor/
git commit -m "update my-dep to latest"

The added advantage is that you have the full git history, and all it's commit messages ("fix bug #123", "refractor xyz") available instead of one mega-diff saying "update v0.9 -> v1.5".

Of course, if you think you don't need this, I won't lose any sleep of someone doesn't use submodules :yum: :orange_heart:


Besides learning intricacies of submodules I'm concerned about what I'm reading here - Captcha Check. I likely look into one of the mentioned alternatives.

Would it make sense for cargo to support c libraries in a different way? I'm not sure exactly what I'd suggest to them. New to rust and cargo.

This seems to check the boxes. Introducing source dependencies. Although, I have no experience with it.

Tbh, it sounds like the author got burnt by one bad experience with submodules and now they think submodules are the devil.

In practice, you only need to learn maybe three commands and make a tiny tweak to CI. It's really not as hard or broken as it's made out to be.

And I suppose if you are limiting it's use within a -sys crate and not using it everywhere for internal dependencies....

Still, seems like could be a useful feature to support for cargo, since C libs use seems commonplace with rust.

I don't think the article sounded that way.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.