Quoting Fabian Grünbichler (2025-09-20 18:14:39) > On Sat, Sep 20, 2025, at 5:59 PM, Jonas Smedegaard wrote: > > Quoting Fabian Grünbichler (2025-09-20 17:31:44) > >> On Sat, Sep 20, 2025, at 4:55 PM, Alexander Kjäll wrote: > >> > On Sat, Sep 20, 2025, 16:43 Jonas Smedegaard <d...@jones.dk> wrote: > >> >> Quoting Alexander Kjäll (2025-09-20 16:08:26) > >> >> > And regarding running tests in debug, debug have additional checks for > >> >> > numeric over-/underflows, something that easily happens when switching > >> >> > between 64 and 32 bit architectures. I believe we catch more bugs if > >> >> > we > >> >> > don't run the tests with --release. > >> >> > >> >> Interesting! Can you point to documentation for this? I would like to > >> >> understand that better. > >> > > >> > Here is a section in the book about it: > >> > https://doc.rust-lang.org/book/ch03-02-data-types.html#integer-overflow > >> > > >> >> > >> >> It has been my understanding that debug mode builds without optimization > >> >> and therefore fails to catch optimization-related errors. > >> > > >> > This is also true I think. > >> > > >> > This would be two different classes of errors, don't know how to > >> > prioritise between them or if we can have them both. > >> > >> there's multiple things "enabled" by the default ("dev"/"test") profile, > >> compared to the "release" one used for building executables: > >> - no optimization (faster builds, but might hide optimization-related > >> issues) > >> - overflow checks (as noted above) > >> - debug assertions (these catch all sort of addition issues) > >> > >> the latter two are not enabled for release builds because they are quite > >> expensive at runtime. > >> > >> IMHO, in particular for autopkgtests where the same crates are compiled > >> possibly tens of times, skipping optimization can mean the difference > >> between testing a code path or not testing it at all, so the current > >> tradeoff seems sensible to me. > > > > Do you mean to say that you consider it a sensible tradeoff to *never* > > check crate tests with optimizations enabled? > > no, I am open to suggestions here. for example, running the dh_auto_test > `cargo build/test` and/or the default features autopkgtest with a custom > profile (basically dev/test + optimizations) might be a sensible > compromise? that should catch most optimization-related issues, while > still keeping (test) compilation times down..
What is sensible to me is to enable optimization by default and support DEB_BUILD_OTIONS=noopt. Then it is clearly visible to Debian developers when a package apply some tradeoff. What I commonly do currently as tradeoff with autopkgtest is to check default feature set on all architectures, and no-features and each feature only on amd64 - declared explicitly in debian/tests/control, and can be extended to prepend DEB_BUILD_OTIONS=noopt to some tests as needed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
