[Scons-users] Dependencies and Pseudo Builders

Mats Wichmann mats at wichmann.us
Tue Sep 8 11:14:38 EDT 2020


On 9/8/20 6:55 AM, Michał Palczewski wrote:

> I would like to start unit tests, grab the outputs (which is useless
> without processing), analyze them, and convert them to XML and HTML
> formats.

Having been here, I'm not sure I think any longer that running the unit
tests "as part of the build" is the way to go - a continuous integration
step of validating a build can as easily be done outside of the build
process, and if you can use one of the available systems that support
this, life gets easier because you're using appropriate tools for the
job.  SCons itself has each commit trigger CI builds by Travis (for a
Linux environment) and AppVeyor (for a Windows environment), through
scripts that drive those two; this causes the unit tests and the
integration tests to be run.  Now for SCons, that's "free", because it's
an open source project; your scenario may be different, and those two
aren't the only choices.  Many people choose to set up their own Jenkins
environment to accomplish the validation step.

If your unit tests were in Python, if you place them under control of
PyTest, it can generate an xml output format which you then can find
readily available parsers for.  This doesn't seem to apply to you -
you've mentioned a Ruby script that generates things, but you might
still want to look around for supporting tools that would fit into your
setup.
whic
> 
> Correct me if I'm wrong:
>  1. I should use Builder instead of PseudoBuilder
>  2. So my Builder should take a list of Program compiled before as a
> $SOURCE
>  3. My Builder may call a Python function instead of calling any app
> (following
> https://scons.org/doc/production/HTML/scons-user/ch18s04.html), that
> function does all that Pythonic things

You can have the ultimate "target" be the report file you build, and
yes, then you can write SCons code which produces it, triggered off the
test binaries, but you'll have to be a little tricky, as existing scons
rules think binaries are suitable end products (targets), but not
sources - that is, there existing rules to transform a no-suffix file
(Linux/Mac) or a .exe (Windows) into something else, you'd need to
produce all that plumbing, or cheat.  The project I was on for a while
used the cheat approach - it made a dummy target which was "built" by
calling Command, and which was marked with AlwaysBuild.  Bill will
probably pop up and tell us how bad an idea that is :)  It wasn't a
satisfactory setup, I can say that much; I wasn't in a position to
either fix it or to know better at the time.





More information about the Scons-users mailing list