can we decouple building and running the unit tests?

[cron2]

Trying to figure out what failed on running unit-tests can be misleading if it's actually compiling unit-tests, but we do not have a separate stage for it (and I'm not sure how to tackle this in our Makefiles).

But I fould find it useful if I could so something like

$ make
$ make build-checks
$ make check

where the second stage would build everything that is needed for "make check", but not actually run anything (I would run the second stage in my tests with ">$log 2>&1" and only print that log if anything fails)...

Not sure how complex it is, but I thought (in the light of the "building the UT fails" for gerrit 1400/v1) that this would also make the BB mails easier to categorize - a build fail is always a no-go, while a t_client test fail can be "external circumstances", so re-run might work

[flichtenheld]

So only building the tests when running them is a design choice from Automake. Other systems do not do this (e.g. CMake). But either way we can probably work around it by just creating a custom target. We have the list of test programs available.

[flichtenheld]

I looked a bit into this. The annoying part is making this recursive. Unless my Google-foo is leaving me Automake doesn't seem to offer an easy way to add new recursive targets. So we might need to add some boilerplate code to every Makefile.am under tests/ 👎

[cron2]

Thanks for looking. Indeed this is a bit nontrivial since autoconf-generated build has no targets to actually build these, so even

make -C tests/unit_tests/openvpn buildthings

is not working right now, because there is no such target

check-am: all-am
        $(MAKE) $(AM_MAKEFLAGS) $(check_PROGRAMS)
        $(MAKE) $(AM_MAKEFLAGS) check-TESTS
check: check-am
all-am: Makefile

need to look into this... (and maybe recursion falls automagically out of it, maybe not).

Assigning this to myself right now, as I want this.