search

cezarmathe / btrfsutil-rs

Safe wrappers for libbtrfsutil.
https://crates.io/crates/btrfsutil
MIT License
6 stars 5 forks source link

use system btrfsutil.h instead (via btrfsutil_wrapper) #2

Closed sprhawk closed 4 years ago

cezarmathe commented 4 years ago

Hello! Have you taken a look at the https://github.com/cezarmathe/btrfsutil-rs/tree/development branch? I moved the bindings to a separate repository: https://github.com/cezarmathe/btrfsutil-sys. Also, this approach of having a header file implies that the developer/user of this library has the btrfsutil development headers installed. Given the fact that libbtrfsutil doesn't change often(not even a patch version bump has happened since this library was created), I think it may be better to keep a copy of the header file itself and a copy of it's license.

Also, not exactly related to this, but I plan on creating a Vagrantfile for a disposable virtual machines for building and testing this library - building requires the runtime dynamic library, which on Ubuntu was introduced only in 19.04, and testing can be a destructive process - after all, a btrfs filesystem is required and it may affect the operating system where the testing happens). I haven't commited anything in a while, though, I have my final exams coming up this week, so I haven't had a lot of free time to work on this library.

sprhawk commented 4 years ago

@cezarmathe I understand. Indeed there are various ways to do this. In my option, when you build it you should ave *-dev installed. I do think that depends on your preferences, this PR could be just one suggestion

sprhawk commented 4 years ago

And on Debian, I think btrfsutil-progs includes both dynamic libraries and development files

sprhawk commented 4 years ago

And why not put -sys in one repo as a sub-workspace project. I see many projects use this " single repo with multiple sub-workspace structure " . Still you can publish as different crate. Again, I think that is author's own preference

cezarmathe commented 4 years ago

@cezarmathe I understand. Indeed there are various ways to do this. In my option, when you build it you should ave *-dev installed. I do think that depends on your preferences, this PR could be just one suggestion

That is correct, I have them installed myself. But the current state of the library requires btrfsutil 1.2.0, and having to install certain package versions for a single C header might not be worth it. Also, for people like me who run a rolling-release distro on a btrfs filesystem, that might not be feasible. Also, I couldn't find a way to reliably install the required dependecies on travis-ci - both the runtime library and the development headers. This leads back to the reason I wanted to introduce a Vagrantfile for Vagrant machines - use Vagrant locally and on travis-ci so automated testing and local development can share the same system.

And on Debian, I think btrfsutil-progs includes both dynamic libraries and development files

That's the same on Arch, too, but assuming this for every distro is not possible.

And why not put -sys in one repo as a sub-workspace project. I see many projects use this " single repo with multiple sub-workspace structure " . Still you can publish as different crate. Again, I think that is author's own preference

I've thought about having a "Cargo workspaces" with both packages under the same git repository, but that can, in my opinion, lead to a messy commit history, which would probably make it harder for someone else to look over what changed over time.

sprhawk commented 4 years ago

I see https://github.com/sodiumoxide/sodiumoxide is using the way what I suggested