[Scons-users] unit testing best practices and parallel builds

[Bill Deegan]

Mats,

The party line is "If you're trying to force order, you're doing it wrong".

SCons is designed to figure out order entirely by specified dependencies.

If you are have having failures sporadically, it's likely there's a
dependency which is under or not specified.

Also SCons doesn't view compiling code any different than any other part of
it's tree, so the unit tests aren't really not part of the build as far as
SCons is concerned.

Unfortunately for your request there's not really a "These builders are
part of phase 2" solution readily available.

You might try using --tree=prune when specifying each of the unit tests and
seeing what's missing, likely that's the fastest way to sort out your
issue(s).

In reality you're probably better off if the unit tests run as soon as they
can?

-Bill


On Mon, Jul 24, 2017 at 6:03 PM, Mats Wichmann <mats at wichmann.us> wrote:

>
> There's a fair bit of stuff on this topic on the internet, I've done
> some of searching and reading, but I thought I'd come here for a few
> opinions maybe.
>
> The project in question is fairly large size (a push to Coverity just
> recently resulted in a claim of 700k lines of code). It has unit tests,
> not nearly as many as it should, but a decent number in the area that is
> generally considered "the API". Because of the size, the build is not
> speedy, and the project is wired up to a Continuous Integration
> framework that builds a whole bunch of combinations of build options and
> host/target platforms, which collectively are used to generate a +1 or
> -1 on each proposed commit from the point of view of "doesn't break the
> build". (There are like a dozen and a half distinct builds now, and it's
> only likely to grow). That, naturally, is a problem if it takes a long
> time to get an answer when requests pile on top of requests, so builds
> default to being as parallel as possible. In fact, the script that the
> autobuilders invoke do this, and since the host has configured the
> various virtual machines "optimistically", as in told they're 16
> processors, so, they're Quite Parallel:
>
> if os.getenv("SCONSFLAGS", "") == "":
>     os.environ["SCONSFLAGS"] = "-Q -j " + str(multiprocessing.cpu_count())
>
> If a build runs unit tests it sometimes trips over itself for no
> apparent reason ("transient" - though there's likely some underlying
> problem to solve), and because of the parallelism, it's sometimes quite
> hard to sort out in the logfile amongst the interleaving messages what's
> happening.
>
> So with all of that intro...
>
> are there Best Practices for making something that isn't really part of
> the "build" but is done at build time - namely running unit tests -
> happen separately at the end of the chain so they're not in the middle
> of the parallel build?
>
>
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170724/a49b41d4/attachment.html>