Re: Build failure tooling improvements

[Roland Illig <roland.illig%gmx.de@localhost>]

Am 23.03.2025 um 22:12 schrieb David Holland:
> On Fri, Mar 21, 2025 at 11:48:07AM -0400, Greg Troxel wrote:
>  > It sounds like you want
>  >
>  >   The "smoke-test" target is conceptually similar to test, but is
>  >   intended to take very little CPU time and real time to run.
>  >   Generally, it should run in less than half of the time it takes to
>  >   build the package.  Ideally, it will verify that the program starts
>  >   and does something right, but it will not attempt to run test suites.
>  >
>  > but:
>  >
>  >   - it's a lot of work to write these
>  >   - I don't think upstreams are going to want to add these
>  >   - it won't work with cross builds
>  >   - it will be testing the binaries in the build tree, using the
>  >     package's mechanisms to find the built (and not installed shlibs)
>
> Providing glue to run it in a VM would fix the last two problems.
>
> (In order to have it be not super expensive, you'd want it to start
> from a preexisting VM image, install just the package and the deps and
> the test script, and run it...)

This could be solved in the same way as with ATF, in that the tests get
installed along the package, so they can be run at any time.

If there were a standard location for the entry point of the test files,
such as ${PREFIX}/tests/${PKGBASE}/smoketest, this sounds as if it could
be automated nicely.

Roland