-
Mostly, this involves moving our controller's core MUL interaction (i.e., all the module init and MUL callback stuff) into a separate file, so we can build the core of controller.c into a lib that we can link unit tests against. In general, this whole thing is nasty, because libmulutil requires some app callback stuff to be defined by whomever is implementing main(), and of course everybody has to link against libmulutil. In this case, since the tests implement main(), we have to do a tiny bit of glue stubs. The amount of future glue code will depend on "unit test" paths into the MUL code... we may have to grow a "test" version of mul_app_main.c, for instance, or make that into a callable library. Anyway, stuff for the future.
6396fd39