Vendor the upstream repository for ethercat-sys

ethercat-rs / ethercat

Rust wrapper for the IgH EtherCAT master

Apache License 2.0

56 stars 18 forks source link

Vendor the upstream repository for ethercat-sys #23

Closed Michael-F-Bryan closed 4 years ago

Michael-F-Bryan commented 4 years ago

To make compiling ethercat-sys easier, is it possible to vendor http://hg.code.sf.net/p/etherlabmaster/code as a git submodule?

The idea being that

the git clone ... && cargo build workflow will Just Work, and it won't impact projects which transitively depend on ethercat-sys
The docs.rs build will complete so you can read ethercat's docs online (build logs)
It's not possible for someone to accidentally use a different checkout of the upstream repository
You can remove this panic

I know the original repository uses mercurial, but there seems to be a way to bridge git and mercurial.

When publishing to crates.io, cargo will just grab the files on disk and not go through git/mercurial. That means people using the published crate won't need to use tools like git-hg.

birkenfeld commented 4 years ago

In principle I agree, the only question I have is about licensing: the Etherlab code is GPL/LGPL. We are fine with MIT/Apache because we're not linking to anything, just using the ioctl interface to the kernel module. But distributing the code might be a problem (IANAL of course).

The other solution is to pre-generate the bindings, of course, but then we have to bless one of the codebases (there is the original Etherlab code, in Mercurial, with several branches, and there is a clone with patches at https://github.com/synapticon/Etherlab_EtherCAT_Master).

Maybe include pregenerated bindings with a feature flag (that is enabled for docs.rs)?

flosse commented 4 years ago

Do you think we could use build.rs to do that? If ETHERCAT_PATH is not set we clone the upstream code?

birkenfeld commented 4 years ago

I think that's more than I would expect/want a build.rs to do, at least without explicitly asking for it.

flosse commented 4 years ago

The other solution is to pre-generate the bindings,

that sounds good :)

of course, but then we have to bless one of the codebases (there is the original Etherlab code, in Mercurial, with several branches, and there is a clone with patches at https://github.com/synapticon/Etherlab_EtherCAT_Master).

We could pick two versions, one for the official and one for synapticon.

Maybe include pregenerated bindings with a feature flag (that is enabled for docs.rs)?

flosse commented 4 years ago

... I'll try to add this to v0.2 (#28)