On Fri, Jul 05, 2019 at 08:37:20AM +0100, Richard W.M. Jones wrote:>On Fri, Jul 05, 2019 at 01:28:12PM +0900, Hiroyuki Katsura wrote: >> > Have you decided whether we need to commit the generated files >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files >> > are still included and not added to .gitignore. >> >> I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to >> .gitignore. However, I think Cargo.toml should be staged. This is because >> this is a file managed by hands. It contains dependencies, versions, >> editions, crate name. It can be generated by shellscript which dumps such >> information. However, I think it may be not preferable. > >OK, no problem. >Just one thing, the Cargo.toml includes a version under which the crate would be published. I presume the version would be the same as the one of the project itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z to crates.io. To make them in sync, it might be better to do it the same way nbdkit does it, having Cargo.toml.in which is taken and the version placeholder is replaced by the actual version.>Rich. > >> Regards, >> Hiroyuki >> >> 2019年7月4日(木) 19:39 Richard W.M. Jones <rjones@redhat.com>: >> >> > On Tue, Jul 02, 2019 at 10:09:00PM +0900, Hiroyuki Katsura wrote: >> > > I fixed the patch I submitted before based on comments, and there are >> > some >> > > commits which are merged or divided. So, I will re-send all the patches. >> > >> > I looked at the v2 patches and I think they're in reasonable >> > shape. >> > >> > There's been a lot of discussion of using ’git rebase --interactive’. >> > I think that's a good thing, and also good practice if you're going to >> > become a more frequent open source contributor. It helps people when >> > they're reviewing patches. >> > >> > For this particular case I think we'd probably squash all the patches >> > into a single commit when pushing them upstream. >> > >> > Have you decided whether we need to commit the generated files >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files >> > are still included and not added to .gitignore. >> > >> > Rich. >> > >> > -- >> > Richard Jones, Virtualization Group, Red Hat >> > http://people.redhat.com/~rjones >> > Read my programming and virtualization blog: http://rwmj.wordpress.com >> > virt-builder quickly builds VMs from scratch >> > http://libguestfs.org/virt-builder.1.html >> > > >-- >Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones >Read my programming and virtualization blog: http://rwmj.wordpress.com >Fedora Windows cross-compiler. Compile Windows programs, test, and >build Windows installers. Over 100 libraries supported. >http://fedoraproject.org/wiki/MinGW
Dear Martin, Oh, I see. Thank you for your information. I should have seen how Cargo.toml is implemented in nbdkit! Regards, Hiroyuki 2019年7月6日(土) 20:03 Martin Kletzander <mkletzan@redhat.com>:> On Fri, Jul 05, 2019 at 08:37:20AM +0100, Richard W.M. Jones wrote: > >On Fri, Jul 05, 2019 at 01:28:12PM +0900, Hiroyuki Katsura wrote: > >> > Have you decided whether we need to commit the generated files > >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files > >> > are still included and not added to .gitignore. > >> > >> I'm sorry I forgot adding Cargo.lock to .gitignore. I'll add it to > >> .gitignore. However, I think Cargo.toml should be staged. This is > because > >> this is a file managed by hands. It contains dependencies, versions, > >> editions, crate name. It can be generated by shellscript which dumps > such > >> information. However, I think it may be not preferable. > > > >OK, no problem. > > > > Just one thing, the Cargo.toml includes a version under which the crate > would be > published. I presume the version would be the same as the one of the > project > itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z > to > crates.io. To make them in sync, it might be better to do it the same way > nbdkit does it, having Cargo.toml.in which is taken and the version > placeholder > is replaced by the actual version. > > >Rich. > > > >> Regards, > >> Hiroyuki > >> > >> 2019年7月4日(木) 19:39 Richard W.M. Jones <rjones@redhat.com>: > >> > >> > On Tue, Jul 02, 2019 at 10:09:00PM +0900, Hiroyuki Katsura wrote: > >> > > I fixed the patch I submitted before based on comments, and there > are > >> > some > >> > > commits which are merged or divided. So, I will re-send all the > patches. > >> > > >> > I looked at the v2 patches and I think they're in reasonable > >> > shape. > >> > > >> > There's been a lot of discussion of using ’git rebase --interactive’. > >> > I think that's a good thing, and also good practice if you're going to > >> > become a more frequent open source contributor. It helps people when > >> > they're reviewing patches. > >> > > >> > For this particular case I think we'd probably squash all the patches > >> > into a single commit when pushing them upstream. > >> > > >> > Have you decided whether we need to commit the generated files > >> > (Cargo.toml, Cargo.lock)? It looks like in this series those files > >> > are still included and not added to .gitignore. > >> > > >> > Rich. > >> > > >> > -- > >> > Richard Jones, Virtualization Group, Red Hat > >> > http://people.redhat.com/~rjones > >> > Read my programming and virtualization blog: > http://rwmj.wordpress.com > >> > virt-builder quickly builds VMs from scratch > >> > http://libguestfs.org/virt-builder.1.html > >> > > > > >-- > >Richard Jones, Virtualization Group, Red Hat > http://people.redhat.com/~rjones > >Read my programming and virtualization blog: http://rwmj.wordpress.com > >Fedora Windows cross-compiler. Compile Windows programs, test, and > >build Windows installers. Over 100 libraries supported. > >http://fedoraproject.org/wiki/MinGW >
On Saturday, 6 July 2019 13:03:24 CEST Martin Kletzander wrote:> Just one thing, the Cargo.toml includes a version under which the crate would be > published. I presume the version would be the same as the one of the project > itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z to > crates.io.Speaking of naming: it seems like libraries that interface/wrap a foreign C/C++/etc library are usually called foo-sys -- so should our binding be named guestfs-sys? -- Pino Toscano
On Mon, Jul 08, 2019 at 10:10:10AM +0200, Pino Toscano wrote:>On Saturday, 6 July 2019 13:03:24 CEST Martin Kletzander wrote: >> Just one thing, the Cargo.toml includes a version under which the crate would be >> published. I presume the version would be the same as the one of the project >> itself, i.e. when releasing libguestfs-x.y.z, we publish guestfs-rs-x.y.z to >> crates.io. > >Speaking of naming: it seems like libraries that interface/wrap a >foreign C/C++/etc library are usually called foo-sys -- so should our >binding be named guestfs-sys? >So you've seen my RFC? =) Just to guestfs-sys would be a crate that does only two things: 1) exposes the C functions using `extern` 2) links to the library And then another crate (e.g. guestfs) would expose the higher-level, safe, hopefully idiomatic API. More information (reasoning etc.) see: https://doc.rust-lang.org/cargo/reference/build-scripts.html#a-sys-packages Martin>-- >Pino Toscano