Hi Michael,

Thanks for your time in reviewing those patches.

Do not hesitate to tell me when I can rework a PR to simplify it, or make it more readable.

If you still have some energy, a new round of PRs is ready here : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse

After this round, there will still be 2 or 3 PRs that will apply cleanly, then we will have to discuss a few things:

Regarding ESP-IDF v4 : I used it because it was an intermediary step (between v3 and v5) with less deprecations, so it was easy to port from v3. ESP-IDF v5 introduced a lot of deprecations and changes, but having done the v4 port gave me confidence that it could be done.
(Note: v4 needs a patch to support WHOLE_ARCHIVE - which I don't know if it is important, or not, to have)

As ESP-IDF v5 is a "recent" release (5.0.0 is 2022-12-2, 5.0.1 is 2023-02-17), it may be possible that some of our dependencies out there are not (yet) ready to be compatible with v5 (while they are OK with v4):

So, to answer your question, I'll try to keep v4 compatibility in my branches for some time in case it's needed - but it's perfectly OK to skip it in the "official" OVMSv3 if it works fine without.


Regards,

Le 24/02/2023 à 17:34, Michael Balzer a écrit :
Ludovic,

I've merged all your PRs, including the two "touchy" ones. I've seen no issues but a couple of bug fixes included.

I still need to test these with idf5 (i.e. the new idf5 branch state), idf3 builds & runs fine.

The IDF version switches of course don't add readability, as expected. But if they can be kept that small, I don't see any problems.

I would opt for excluding the IDF 4 branches, to aid in keeping these as small as possible. I don't see any advantage in IDF 4 over 5 -- do you?

Regards,
Michael


Am 22.02.23 um 17:23 schrieb Ludovic LANGE:
Hi Mark,

You're certainly right : WolfSSH writes here https://github.com/wolfSSL/wolfssh : "wolfSSH is dependent on wolfCrypt, found as a part of wolfSSL".

So it seems we need to bundle it still, and it's a good thing we managed to have it more or less compile with ESP-IDF 5+ (a few bugs are still being ironed out - especially the OPENSSL compatibility layer, which may not be used if mongoose does use mbedTLS instead).

Regarding the integration, I tried (my best :-)) to have it build on both ESP-IDF 3, ESP-IDF 5 (and also ESP-IDF 4 with a small patch to the ESP-IDF build system itself). Of course I need help for testing / reproducing the builds and I'm grateful to those of you sparing some time to do exactly that.


-> @List, do not hesitate to have a look - especially for the ones that are a little bit touchy:

Thanks in advance !

Regards,

Le 20/02/2023 à 08:07, Mark Webb-Johnson a écrit :
Michael, Ludovic,

Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?

My memory was that wolfssh required wolfssl? But I may be mistaken.

We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition.

If this can cleanly be applied to the existing work, to allow building under either v3 or v5 IDF, that would be ideal. IMHO, the separate branch would only be required if the changes were very extensive and breaking to v3.

Regards, Mark.


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev