Can you think of any use case for that?

I guess the prime answer would be: Writing unit tests for your applications that you don't want to merge into master.

But more important for me was that this change makes the embUnit "module" less of a special case. E.g. there's no more a reference to embUnit in Makefile.application.

I fear a little bit that we then get unittest applications galore, while the current design enforces developer to centralize them in the 'tests/unittests' application.

@authmillenon I'm not afraid of that.

If you tell me then every time I like to test a module where to find its unittests ;)

@Kijewski since you've made some crucial changes to embunit: should we present them to upstream?

I didn't mean I wasn't afraid of the results of unittest fragmentation, I am not afraid the fragmentation is going to occur because we have this review process.

(And we also have documentation on how to write unittests and we already have a centralized structure which will provoke it's continued usage.)

(Because the review process is always perfect ;-))

I'm glad you see it that way ;)

Nevermind if users should use this module or not. This PR removes the ugly special cases in for embUnit in Makefile.application.

@authmillenon do you NACK this? If not please say so.

No... Go on if you must ;)

@Kijewski I assume you are unwilling to fix the doxygen warnings?

I assume you are unwilling to fix the doxygen warnings?

For now, yes. :)

(needs rebase)

rebased

ACK & go