updates for lwip2

[d-a-v]

this PR brings lwIP-v2 to Sming.
original lwIP source code version (stable 2.0.2) is pulled as a sub-sub-module.
To use it, use this environment variable (edit: was LWIP_FLAVOUR):

ENABLE_CUSTOM_LWIP=2

Comments are welcome.

[slaff]

See the comments that are part of the review. In short

• it would be better to simplify the makefile changes
• it would be better to have the lwip2 include files coming from the third-party module.

[slaff]

@d-a-v The "compiler" directory is not the right place to put the include files for LWIP 2. They should be part of the submodule and ideally should end up in third-party/lwip2/include

[d-a-v]

agreed

[slaff]

@d-a-v We can read the value of the ENABLE_CUSTOM_LWIP and if it is 1 then we will use the esp-open-lwip version 1. If it is 2 we will use the lwip2 code. This way we don't have to introduce yet another directive.

[d-a-v]

agreed

[slaff]

@d-a-v Is that really needed here? Won't it be possible to add it to the lwipopts.h file or just patch the stock lwipopts.h that is coming with your repository?

[d-a-v]

I was lazy :) it has moved outside from sming.

[d-a-v]

@slaff all change requests are addressed

[d-a-v]

I synchronized this PR with the latest commits. I hope this is the best thing to do.
Please advise if this is unwished so I can roll that backwards.

[slaff]

I synchronized this PR with the latest commits.

Please, rebase your branch on develop. This way we can see easily only your changes.

git checkout develop
git pull
git checkout <your-branch>
git merge develop
git rebase develop
git push -f <your-origin> <your-branch>

[d-a-v]

Done, thanks :)

[slaff]

@d-a-v There are a lot of renamed files in this PR. For example "Sming/system/include/arch/cc.h → Sming/system/esp-lwip/arch/cc.h". Please, revert those renames because we still need them if someone decides to compile Sming with the stock LWIP.

[d-a-v]

This is true. The problem is that Sming/system/ does include lwip but also some Sming's system files. If they were separated, then the renames would not be needed.

The stock lwip could (and should) still be used, at the cost of one more "-Ipath/to" gcc option. I'm open to any solution, but for lwip2 to freely live inside Sming, lwip must be out of the way (but still around - at least the include files - because it is needed for building lwip2).

[d-a-v]

Also, now lwip2 uses espressif's lwip include files (because some definitions are subject to changes, like recently with the new definition of lwip_err_t). It seems Sming has a decorrelated copy of these include files. For instance, the dhcps_pcb field in netif is not in Sming, but is in esp-lwip-sdk and in esp-open-sdk too.
Since Sming depends on esp-open-sdk, I would suggest, if lwip2 is to be included, that Sming sources files may directly use esp-open-sdk's lwip include files. I rekon this would be a significative change (not that much in sources), but since the library comes from there, why not taking the matching include files too.

[d-a-v]

Note that in the current PR, lwip is still usable (gcc -I options are accordingly updated to the directories where lwip includes files are moved).
Another solution would be the following: all lwip include files should be removed from Sming itself, and used from esp-open-sdk, as proposed above.
lwip2 can be proposed to esp-open-sdk (it's in progress) so once it's done, Sming could take benefit from this.
Still, the changes in SmingCore/Network/ are mandatory.
What do you think ?
Should I close here ?

[slaff]

What do you think ?

@d-a-v Your suggestions sound reasonable. I just need time to evaluate the best way to go. The fact that we support multiple SDKs or different OSes, some of which have wrong or incomplete LWIP headers is the reason to have them as part of the library.

In addition I experimented with less intrusive code changes on our side that you can see from here: develop...slaff:feature/lwip2#diff-5d6d3354bd9d34ab47696d7f7088ea65

One question: If LWIP2 is used there is no possibility to use espconn_* methods, right? Is that correct or wrong?

[d-a-v]

Your changes are elegant :)
So I'm confident you can find another elegant way to separate lwIP include files from Sming/system/.
About espconn_* there is no reason why they could not be forwardported using the same LWIP_IP_ADDR_T-like definitions. I did not try to do it because they are not called from the binary libraries nor the arduino ones. dhcps is an app that was forwardported and it's been done without much hassle.

[slaff]

Will be merged with rebase #1289.