Drop glib dependency for unit tests

[nemequ]

This would make Windows, where things are more complicated than just apt-get install libglib2.0-dev or dnf install glib2-devel, much easier to deal with.

tinycthread has a very rudimentary test runner we could steal (unless I can find something better). Some modifications would probably be necessary, but it's doable.

[jibsen]

There are tons of unit test libraries available with varying levels of functionality.

I've used greatest before when I just needed to run simple tests.

[nemequ]

I ended up putting together a small framework called µnit. I'm still working on the API in a couple places, but I think it's mostly ready to go. I'll start working on porting over the existing tests soon.

[jibsen]

I noticed it yesterday, looks interesting 👍.

[nemequ]

@jibsen, when you have some free time, would you be willing to take a look at AppVeyor for the wip/munit branch? It builds fine, but execution doesn't work; I think it's just a small issue with CMake, but it's a bit tricky to debug just by looking at the AppVeyor output.

FWIW I'd prefer to just have tests/test-squash.exe executed instead of going through ctest for AppVeyor, but make test needs to work regardless…

[jibsen]

The test should run on AppVeyor now, but they crash with MSVC due to a call to squash_get_codec passing NULL. I don't have time to look into it right now, but the tests appear to run reasonably with MinGW, so it must be something MSVC specific.

[nemequ]

Thanks! I'll look into it tomorrow. I suspect it's not seeing the plugins, which is interesting…

The mingw build doesn't actually run the tests; that would require installing wine, which wants to pull in the whole graphical stack.

[jibsen]

I suspect you are right.

Rearding MinGW, I meant locally on my machine. Compiling with mingw-w64 the new tests run, and tests 14 and 15 segfault on the ms-compress plugin. Perhaps it is the stack usage issue again.

[jibsen]

The tests are running now.

Looks like I accidentally pushed some code to increase the stack limit along with the fix for the plugin path in 6656416.

[jibsen]

The crash in lzg appears to have been fixed upstream.

Looks like I was wrong, I filed a PR (mbitsnbites/liblzg/pull/4).