Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Espressif examples run with local wolfSSL (no setup!) #6018

Merged
merged 13 commits into from
Feb 13, 2023

Conversation

gojimmypi
Copy link
Contributor

@gojimmypi gojimmypi commented Jan 27, 2023

Description

Helpful for wolfSSL Espressif first-time users: This PR allows the examples to just work without needing to manually install wolfSSL as an Espressif component.

Helpful for wolfSSL Espressif developers: This PR allows live changes to be made in the code that's actually in the repo. Otherwise the executing wolfssl code would be in the $IDF_PATH components directory, with any changes needing to be copied back to the local repo to be checked in to GitHub. After doing this wonky thing as part of my build process, well... enough was enough. Allowing in-place editing is how things are supposed to work.

This PR also addresses the "exactly what version is this" question a bit more gracefully than the install-time edit of source code in PR#5955. This particular implementation is for the local wolfSSL examples only. The component install method will need a slightly different implementation.

See #6234 for a roadmap of Espressif updates.

Fixes zd# n/a

Testing

Open wolfSSL VisualGDB projects as usual, or run with ESP-IDF idf.py build flash. The examples will run without needing to install wolfssl! If wolfSSL is already installed, there will be a warning about having multiple installs, but the code should still run properly, provided the existing wolfSSL install is valid.

Checklist

  • added tests
  • updated/added doxygen
  • updated appropriate READMEs
  • Updated manual and documentation

@gojimmypi gojimmypi requested a review from dgarske January 27, 2023 06:05
@gojimmypi gojimmypi self-assigned this Jan 27, 2023
@gojimmypi gojimmypi requested a review from bandi13 January 27, 2023 06:05
@gojimmypi
Copy link
Contributor Author

Jenkins retest this please

@gojimmypi
Copy link
Contributor Author

Including a reference to espressif/esp-idf#9929 (comment) that has this valuable comment on Espressif component CMakeLists files as related to changes in this PR:

[...] component CMakeLists files are evaluated twice during the build process. First, they are evaluated early during the build in CMake script mode to extract component requirements (REQUIRES and PRIV_REQUIRES arguments of idf_component_register). Evaluation stops after encountering the call to idf_component_register() or a return(). Once the list of components has been determined component CMakeLists files are evaluated again, this time using the normal add_subdirectory call.

That's where I got the idea to wrap some items in the CMake like this:

if(NOT CMAKE_BUILD_EARLY_EXPANSION)
  # things to parse only once ...
endif()

Copy link
Contributor

@bandi13 bandi13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Over all, you seem to have a lot of duplicated code in your CMakeLists.txt. Would it make sense to have a common section of the file in a parent folder which each example references? Then you could have the unique parts in the individual examples.

Might also want to consider having a common initialization.c file for each of the main.c/wifi_connect.c files. At the very least have consistency in calling the file main.c.


#if defined(WOLFSSL_MULTI_INSTALL_WARNING)
ESP_LOGI(TAG, "");
ESP_LOGI(TAG, "WARNING: Multiple wolfSSL installs found.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems like something that should be a compile time warning. Not runtime.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it's both: as the make/build process is rather long and the build warning could be missed.

It would be good to include the app as well for higher visibility.

# wolfSSL found in both ESP-IDF and local project - needs to be resolved by user
#
message(STATUS "")
message(STATUS "WARNING: Found components/wolfssl in both local project and IDF_PATH")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe consider making this an error and not just a warning. Bad/unexpected things could happen because of an unreliable location of the component source files.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had considered making it a failure. But I wanted to to be a "it just works" feature. Sure, the user may have an different version installed, but do you think that should really make it a hard fail? This method we are pointing out which is being used, with a warning in the app (noted above).

It might however, be a good idea in a future revision to determine the versions of each and display that information as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've reconsidered this and yes: I'll submit a change to make this a hard fail error. The risks of mixing code from each of the (potentially different version) component directories if the user ignores the warning seems ripe for support headaches.

message(STATUS "")
message(STATUS "WARNING: wolfSSL not found.")
message(STATUS "")
else()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove unnecessary 'else' block

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch! Actually I was missing a message, so the else() stayed and I added a message regarding path.

@dgarske dgarske removed their assignment Jan 31, 2023
@gojimmypi
Copy link
Contributor Author

duplicated code in your CMakeLists.txt. Would it make sense to have a common section of the file in a parent folder which each example references?

I assume you mean across the different projects? Yes. This is as intended; I realize that there could be a more efficient way for this group of examples. Instead, this design pattern is for portability: just take the CMakefiles.txt, plunk it into a project ./components/wolfssl/ and assign the appropriate WOLFSSL_ROOT value. Having some sort of CMakefile include reference would reduce that flexibility and result in something much more fragile.

@gojimmypi
Copy link
Contributor Author

duplicated code in your CMakeLists.txt

In the latest update, I added a CMake function that is easier to understand and use.

@gojimmypi gojimmypi requested a review from bandi13 February 1, 2023 05:10
@gojimmypi
Copy link
Contributor Author

Jenkins retest this please

1 similar comment
@gojimmypi
Copy link
Contributor Author

Jenkins retest this please

@gojimmypi gojimmypi marked this pull request as draft February 6, 2023 20:17
@gojimmypi gojimmypi marked this pull request as ready for review February 7, 2023 13:20
@wolfSSL-Bot
Copy link

Can one of the admins verify this patch?

Copy link
Contributor

@dgarske dgarske left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Mac:

./IDE/Espressif/ESP-IDF/compileAllExamples.sh
Found IDF_PATH = /Users/davidgarske/GitHub/esp-idf
~/GitHub/wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_benchmark ~/GitHub/wolfssl
Traceback (most recent call last):
  File "/Users/davidgarske/GitHub/esp-idf/tools/idf.py", line 45, in <module>
    from idf_py_actions.tools import (executable_exists, idf_version, merge_action_lists, realpath)  # noqa: E402
  File "/Users/davidgarske/GitHub/esp-idf/tools/idf_py_actions/tools.py", line 1, in <module>
    import click
ImportError: No module named click
~/GitHub/wolfssl
Failed in benchmark

Both python and python3 have "click" installed...

% pip install click
Requirement already satisfied: click in /usr/local/lib/python3.10/site-packages (8.1.3)
davidgarske@Davids-MBP wolfssl % pip3 install click
Requirement already satisfied: click in /usr/local/lib/python3.10/site-packages (8.1.3)

@dgarske dgarske removed their assignment Feb 13, 2023
@gojimmypi
Copy link
Contributor Author

gojimmypi commented Feb 13, 2023

@dgarske Thanks for taking this for a test drive. Can you please confirm you have a standard ESP-IDF release install? It appears from the message that you may have a special (GitHub clone? modified? non-release?) version in your /Users/davidgarske/GitHub/esp-idf directory. That's typically not a default install location.

Could you please try from the default Espressif release install and let me know the output? For example:

# switch to your installed test of PR6018
cd ~/
git clone https://github.com/gojimmypi/wolfssl.git wolfssl_PR6018b_test
cd ~/wolfssl_PR6018b_test/IDE/Espressif/ESP-IDF 
git checkout Espressif_No_Install

# setup ESP-IDF
. ~/esp/esp-idf/export.sh

# build all the examples
./compileAllExamples.sh

I'm also curious as to exactly which version you are attempting. Could you please let me know the result of idf.py --version

I've tested this with both ESP-IDF v4.4 and v5.0 on WSL and a "real" Ubuntu VM, but I don't have a Mac to test your exact setup.

  • edit: Also consider building individual projects:
cd ~/wolfssl_PR6018b_test/IDE/Espressif/ESP-IDF/examples/wolfssl_test
idf.py build

@dgarske
Copy link
Contributor

dgarske commented Feb 13, 2023

That worked. I needed to checkout the normal esp-idf master and run the ./install.sh.

@gojimmypi
Copy link
Contributor Author

Note there's a new hard fail for wolfSSL being installed in both the ESP-IDF components directory and this new local component makefile. After a discussion with @bandi13 we decided it would be an unnecessary challenge for support in determining which source was being used, and perhaps even a non-zero chance of cross-contamination between them when each is a different version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants