Le jeu. 20 avr. 2023, 17:00, Khem Raj <[email protected]> a écrit :

> On 4/20/23 2:57 AM, Frederic Martinsons wrote:
> >
> >
> > Le jeu. 20 avr. 2023, 11:41, Richard Purdie
> > <[email protected]
> > <mailto:[email protected]>> a écrit :
> >
> >     On Thu, 2023-04-20 at 09:27 +0200, Frederic Martinsons wrote:
> >      > Hello,
> >      >
> >      > I would like to build and ship tests for recipes which uses cargo
> and
> >      > in the process, three questions arose (maybe more when I will
> >      > progress).
> >      > I would like to have your opinions on them.
> >      >
> >      > 1) should we ship cargo-native in ptest images or should we just
> >      > build and ship test binaries alone ?
> >
> >     ptests run in target images so they'd depend on "cargo" and cargo-
> >     native wouldn't be appropriate.
> >
> >
> > Of course, I meant cargo, not cargo-native.
> > I'm asking for that because running "cargo test" to execute the whole
> > test suite is the standard for rust project but it will force us to
> > embed cargo (plus all it's deps) and source code for doing that. I think
> > I will go for the test binaries only for the moment. Note that I will
> > need to do some "clever" search of them because they do not have a
> > deterministic name (https://github.com/rust-lang/cargo/issues/1924
> > <https://github.com/rust-lang/cargo/issues/1924>)
>
> Usually ptests are cross compiled during build and results are packaged
> into PN-ptest package. A run-ptest script is added to this package which
> is used to execute the tests on device. This also integrates with
> ptest-runner and larger system testing if you wish to do so. in some
> cases we
> might package tools needed to run the tests on target but seldom do we
> compile the tests on target and then run them because embedded targets
> may not have enough musle to do that. So if cargo binary is needed to
> run the pre-compiled tests then I think adding that to rdeps of PN-ptest
> might be fine.
>

Yes, thanks, I'm aware of PN-test package and run-ptest script, this is
what I plan to do.

But I don't think embedding cargo is desirable, since issuing "cargo test"
command doesn't imply to run pre compiled binary, this will compile the
project and run tests onto (pretty like what a Makefile project would do
with "make check"), so this would imply to pull a lot of dependencies for
that (though I don't how many exactly)

>
> >
> >      > 2) should we place the cargo ptest specifics in a dedicated class
> >      > (e.g ptest-cargo.bbclass, like already existing ptest-gnome or
> ptest-
> >      > perl) or put this in cargo.bbclass itself ?
> >
> >     If ptests for cargo all follow a common format and a class can enable
> >     them for a large set of recipes, a class is appropriate.
> >
> >     If would only be in cargo.bbclass itself if all cargo recipes had
> >     standard ptests.
> >
> >
> > Yes they do follow a common format for all rust projects (except for the
> > generated binary name, see above). But a recipe can perfectly choose to
> > not implementing any tests if they want to.
> > I'll go for a separate class to clearly distinguish test things in a
> > first time.
> >
> >
> >      > 3) should we embed all kind of tests (unit, integration and doc
> >      > tests, see
> >      > https://doc.rust-lang.org/book/ch11-03-test-organization.html
> >     <https://doc.rust-lang.org/book/ch11-03-test-organization.html>) or
> >      > just the unit tests ?
> >
> >     I don't know about the rust specific details but unit and integration
> >     tests are both appropriate. I've no strong opinion on doc tests.
> >     They're probably fine if they don't add large dependency chains and
> run
> >     quickly.
> >
> >     Cheers,
> >
> >     Richard
> >
> >
> > OK I'll see how doc tests behave for already existing recipes (if they
> > have some).
> >
> >
> >
> > 
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180255): 
https://lists.openembedded.org/g/openembedded-core/message/180255
Mute This Topic: https://lists.openembedded.org/mt/98384286/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to