[Scons-users] Build and run unit tests automatically on target build

[Matthew Ryan]

Thanks for these pointers; I'll have to experiment a bit, but I do
believe I can use them to accomplish what I want.

 - Matt

On Tue, Jun 18, 2024 at 6:25 AM Andrew C. Morrow
<andrew.c.morrow at gmail.com> wrote:
>
>
>
> On Mon, Jun 17, 2024 at 3:27 PM Matthew Ryan <mjr at centauri.org> wrote:
>>
>> I've been looking for some way of building and running a unit test
>> after another target is run, but so far have been unable to come up
>> with a recipe.
>>
>> The specific example is that of a C/C++ static library built by
>> `env.Library()` - I want a setup where, whenever the static library is
>> rebuilt, a unit test (built by `env.Program` and linked against the
>> static library) is built and run automatically, and if it fails, the
>> build fails, so anything later on that links against libfoo would not
>> build.
>>
>> Is such a thing possible?
>
>
> I think it is definitely possible.
>
> What you are trying to express amounts, I think, to the following: if target B depends on target A, then target B also depends on building and passing the test for target A. Now, there may be many B, C, D, ... which all depend on A, and you only want the test to run once. So you don't really want to depend on running test A so much as you want to depend on the results of running test A. So the dependency graph looks like:
>
> A < {B, C, D ... }
> A < A_test < A_test_proof < { B, C, D, ... }
>
> Where `A_test_proof` is a target which runs A_test, stores the result, and builds or fails based on the result.
>
> So now the trick is to have the existence of an A < B edge automatically induce an edge A_test_proof < B. You can do this, perhaps, by writing and adding a target scanner to the Library builder. One very nice property of what you are proposing is that it will work with CacheDir, such that if library A is altered and then restored, test results should be able to be cached, as can Library objects which depend on those test results.
>
> For some prior art on adding "proof" targets of that type, see https://github.com/mongodb/mongo/blob/e75ae66953915b7d0d63188268bbf10497b40c65/site_scons/site_tools/mongo_test_execution.py. It works a little differently because it doesn't automatically make the build depend on passing tests and just creates aliases, but it should show how to build the targets for executing the tests in a way that respects caching. For some related art on automatically adding dependencies with a scanner, see https://github.com/mongodb/mongo/blob/8a7b5d451fd706a2ff0ad6c43c3a1f7c88264070/site_scons/site_tools/forceincludes.py
>
> Note that I don't think you want to make building the actual liba.a or whatever require running the test. There might be good reasons sometimes to want to produce just the library file as a target without failing the build. That's why I like the idea of making the requirement be that it is only use of the library in another target that automates execution of the associated test.
>
> You can probably also make use of Emitters to automate creation of the test.
>
> What I'm suggesting is probably only one of many ways to get SCons to do what you are suggesting.
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users