Interesting

@kaspar030, may be it will be better to add new flag DISABLE_MESSAGING instead of MODULE_MSG - it makes more sense.

I think is important PR, because not in every case we need messaging, especially if RIOT controls simple sensor node.

Sorry, this got lost somehow. Could you rebase, @kaspar030?

• rebased

I'm not sure, I see a concrete use case for that right now, but increasing modularity and making more features optional seems always a good idea if the overhead is manageable - which is the case for this change.

I've re-done the PR, it felt pointless to create a whole directory for msg, now I'm using ifdef within msg.c.

I've moved thread_print_msg_queue() to msg.c and renamed it to msg_queue_print(). @authmillenon, do you approve?

I would prefer creating a new directory. Other then that msg_queue_print() is okay. :-)

(especially since compilers will complain about the empty compile unit).

((I saw enough of this type of "modulization" in lwip and emb6 that I know I don't want to have that in RIOT ;-)))

I would prefer creating a new directory.

why?

(especially since compilers will complain about the empty compile unit).
AFAIK, not if there's a single valid source line (e.g., headers).

I gave already a bunch of reasons but here are more:

• it's ugly
• it gives a bad example and will enable future contributors to provide modules the same way
• it's hard to assign binary data to modules (not in this example, but in lwIP - which uses only this kind of moduling - it definitely is a problem)

Compared to that:

• moving it to a directory isn't hard ;-)

Martine, how is it possible that we end up having completely opposite opinions on so many matters? ;)

I gave already a bunch of reasons but here are more:
No you didn't. You gave one, which I think is invalid.

it's ugly

Subjective. I don't agree. At least it is a lot less ugly than a subdirectory.

it gives a bad example and will enable future contributors to provide modules the same way

this is not the first module to do this.

it's hard to assign binary data to modules (not in this example, but in lwIP - which uses only this kind of moduling - it definitely is a problem)

Meaning - what?

Compared to that:

moving it to a directory isn't hard ;-)

It was in a subdirectory before the last commit(s). That looked ugly and completely unnecessary.

Mind you - the whole idea of disabling messaging is more an excercise of "because we can".
If it adds a pseudomodule and an #ifdef'd code block, fine. If it adds another directory (and thus becomes the only core .c file not in /core), it feels too intrusive to me for what it can do.

One-file modules in their own directory always seemed like a deficiency of the build system anyways.

Hm, difficult thing. On the one hand, having a subdirectory is kinda ugly, particular since it would be the only subfolder in core. On the other hand, this ifdef bracket around basically a whole file is kinda ugly, too. But finally, we cannot do this without some ifdefs anyway, so I'm willing to accept the current solution.

Well if #4919 is imported and also added as a directory msg wouldn't be the only directory in core ;-). Also: I like directories they are not ugly :P.

But fine. If I'm the only one that diggs subdirectories I'm fine with #ifdef blocks

this is not the first module to do this.

Which other pseudo-module does this? I see only dependency-collecting modules, modules that are only header files, common API modules, and "pseudo-submodules" (modules that add additional functionality to an existing module) in Makefile.pseudomodules. There is no module that is exactly like a normal module, but is a pseudo-module because the complete code for is in an #ifdef.

Needs a rebase.

I like the PR and I agree with @kaspar030, that I don't really like putting it into a separate folder. The only thing I think could make sense, is to rename the module to core_msg, to make clear that this module is part of core. @authmillenon can you live with this?

so 1st ACK

Yeah.

• rebased, now waiting for core: add thread flags #4103 as some lines are changed by both

Would someone give a second ACK?

green! :)

One minor doc thingy. Otherwise, fine... ACK

Thx! addressed & amended.