Document module dependency matrix

[marcelstoer]

It's helpful I can easily include/exclude particular modules for custom builds using user_modules.h. However, this is always trial-and-error I assume because there's no documented module dependency matrix. If I exclude module X will my NodeMCU binary be broken because module Y depends on X?

This request is to maintain (in wiki) or auto-generate a module dependency matrix.

[marcelstoer]

I was just wondering if that's even necessary. Could it be that all modules are, or have to be, independent of each other anyway?

[vowstar]

TODO:
Build firmware dependent tree and make all modules more dependent.
@MarsTechHAN @vowstar

[MarsTechHAN]

But like SSL, some modules wont use it, and SSL will consume a lot RAM...

How about make a trick?

#ifdef MQTT

#define SSL

#endif

And cross-test will consume some time...We will get this done in a week.

[marcelstoer]

How about make a trick?

MQTT is the only module that fails the build if SSL is disabled, see #432 (there's a note about this in my cloud build). Hence, once this is fixed the SSL setting is totally independent from other settings. IMO that's the way to go.

I'd welcome if you postulate a guideline which says that all non-core modules (e.g. MQTT, 1-wire, I²C, cJSON, etc.) must be standalone and not depend on any other non-core module. Running makedepend or the compiler with the -M option could provide some automatic dependency analysis.

[TerryE]

Ladder logic tricks like this are pretty standard but typically you would have the primary defines as a block and the dependency defines as a second block so in this you'd have something like

#if defined(MQTT) && !defined(SSL)
#  define SSL
#endif

This is the simplest and tidiest way to add such dependences

[confile]

+1

[marcelstoer]

@TerryE @devsaurus @jmattsson @pjsg This starts to bother me more and more and I'm quite convinced that it'll bite us medium-/long-term if we don't tackle this. When I created this issue nearly a year ago we had maybe 20 modules, now there are more than 40.

Initially I thought it would be enough if we had a simple dependency matrix. However, meanwhile we have different sorts of dependencies.

• classical, module A requires module B: currently with Net functionality rewrite on top of LWIP #1379 it looks like you'd need the new tls module for net, http and mqtt if you want secure connections
• exclusive shared resources: hw_timer used by PCM and others
• individual modules intended to be used together: rtctime, rtcmem, SNTP
• de-facto dependencies: RFD - SD Card support #1321, "User is then free to choose how to generate this info. Preferably from rtctime.get()"

Do you think it'd be feasible to maintain a n*n matrix (n=number of modules) and give intersecting cells a specific color (see list above)? If further clarifications are required colorized cells may contain foot note references of course. Can you think of a more sensible approach?

[jmattsson]

Visualising dependencies is tricky. A colour-coded matrix is probably not a bad choice, but I am a bit concerned about its size when we get to e.g. 80 modules. Right now I can't think of anything smarter though, but I'll sleep on it and see if anything pops into my head.

[pjsg]

There are two aspects to this -- one is to make the build work with arbitrary combinations of modules and the other is to make sure all the required functionality is present.

For the first, I think that the code ought to get it right (i.e. have the dependencies in some header file).

For the latter, the situation is a little more complex - but I don't think that there are many cases here. The TLS situation is the most obvious. I don't mind this being explicit.

For the sntp/rtctime case, I'm in favor of just treating these as hard dependencies and using the header file approach.

For the hw_timer case, this is already handled by the build system -- it is always only included if some module that needs it is included (this is the linker magic).

Presumably it would be possible to write a script that, given a list of lua files, extracted all the names that need to be defined and thereby could extract the required module list.