Re: Build failure tooling improvements

[Rob Whitlock <rwhitlock22%gmail.com@localhost>]

> On Mar 21, 2025, at 11:48 AM, Greg Troxel <gdt%lexort.com@localhost> wrote:
> 
> Rob Whitlock <rwhitlock22%gmail.com@localhost> writes:
> 
>> I occasionally run into the issue that a program builds but crashes on
>> startup. A suggestion would be to have some sort of smoke test that
>> runs the program and checks for that sort of thing. That would
>> probably be package-specific though, and would likely have overlap
>> with any test target that might already be present.
> 
> 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.

Yes, except that it should take much much less time than 50%.
I was thinking something that would just start the program, quit
the program, and check for a core file. But even that might be
challenging to do for graphical apps, which incidentally is where
most of my concern lays.

> but:
> 
>  - it's a lot of work to write these

Yes, the more I think about it, the more I think it would be really
easy to slide down the slippery slope of implementing a more-or-
less full test suite framework. But the intention is to have a
dirt-simple per-package implementation and a simple pkgsrc
infrastructure implementation. If this cannot be done, it would
probably be better to not have a smoke-test target and just
have regular tests from upstream.

>  - 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)

Good points.