Build process automation #5
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The script is setup to take in, as its first parameter, the name of the example to build. This is then checked against the valid examples and matched with the associated directory. The directory is then checked for in the current path - if not, it's an indication that the script was not sourced from the project root.
The script now sets up the virtual environment directory and installs the required python dependencies from requirements.txt. Note: This script may have compatibility issues with Windows that will be addressed in a separate issue.
This commit saw a few major changes, including a correction to the target board variable. The mount point is now passed in as an argument to the script as there's an issue with flashing with mbed-tools; please refer to issue #282 on the mbed-tools repository for more information. As a result, the binary is flashed manually.
The script has many caveats that are addressed as a comment on the associated issue (or pull request). These are mainly as a result of dependency conflicts between mbed-tools, mbed-os, and pyocd. The updated script follows the build instructions as listed in the documentation accompanying this example (with additional checks).
This commit is the first in a series of refactoring commits. It introduces a new tool, fota.sh. This commit sets up the script with an author's note and a function to display the tool's usage.
The options passed into the script are parsed and stored in the corresponding variables. Note that some of these variables have default values (as indicated by the usage message).
This commit also removes the print_options function, which was created to help debug the functionality of the parse_options function.
The file is setup with constants for text formatting.
The say function prints a message to the console with formatting based on the selected formatting mode. For now, the error message functionality of this function has been implemented. Refer to the comments in the script for more information.
The function prints an error message to stderr and exits or returns with a code of 1 based on the fail mode, which is passed as an input. If the file is being sourced, then "return" would be passed in; else "exit" would be passed in. This function invokes the say function created earlier with the error formatting mode.
Previously, the parse_options function required that the option be followed by an '=' symbol and the value (i.e -o=value or --option=value). The usage instructions separate the option and the value by a space and the function was modified to meet this requirement. The following stack overflow post proved quite useful in understanding how options are parsed - in fact, the "Bash Equals-Separated" part of the accepted answer was adapted for the intial implementation. https://stackoverflow.com/a/14203146
The parsing function would loop indefinintely if there was no value associated with an option. There is still a need to check if the default value of the options have been cleared, in which case the prior default must be restored or an error must be displayed indicating that the option was not followed by a value.
This commit rolls back the parsing function to it's state in commit a58f3b9. The equals-separated parsing seems a bit more robust than space-separated parsing. I did experiment with getopt, which didn't work as the version pre-installed on macOS doesn't support long option parsing. The 'enhanced' getopt would require a separate installation - at this phase, a python script seems easier.
The fota script now sources the utils script and uses the fail and setup_formatting functions to handle the error of unrecognised options in the parsing phase.
A note is displayed if no mount point is specfied indicating that the binaries will have to be flashed manually.
The function valid_examples checks if the example variable is one of the supported examples. If not, it fails with an error message to stderr and exits.
The only supported board at this moment is NRF52840_DK. However, the support for DISCO_L475VG_IOT01A will be added soon. This function would then require an update.
This is the only supported toolchain as of now. Support for the ARM toolchain may be added in the future.
This commit has also modified the clean function to include the venv folder.
The function installs the requirements through the virtual environment pip and notifies the user if there's any problem. Also, a success message was added at the end of the clean function.
This change introduces the build_example function that calls a dummy build function in the corresponding example's shell scripts (mock.sh and mcuboot.sh). It also passes the valid arguments to this build function. The next few commits will see work on these functions, starting with the build in mock.sh.
Previously the quotes were places around all the arguments, making it a single argument to the example build function (accessible through $1). Now, each individual argument is wrapped in quotes, making them separate arguments.
The note formatting is intended to provide information on any known issues in the build process or to bring the end-user's attention to some important information.
The message is now updated to use the note formatting and the second line was dropped as it was redundant.
The build instructions were adapted from those defined earlier in build.sh. This function has been verfied to work with the supported target board and supports building without a mount point.
Create mock_clean and mcuboot_clean; the latter is still a dummy function. The former has been implemented and verified to clean the target build directory and dependencies directories.
The build instructions for the requirements installation were adapted from those defined earlier in build.sh, albeit with minor changes.
These instructions go upto the point where the original virtual environment is restored. The last step would involve some input from the user to modify the mbed_app.json file in the application folder.
This is quite a significant commit - the script now prompts the user on whether it should auto-update the application/mbed_app.json file; this serves well for testing purposes where the "yes" would be piped into the script. Also, part of the script was adapted from the prior implementation in build.sh. Note that this introduces a new dependency "jq" that's not installed through pip - rather, it requires some manual intervention on the end-user's behalf.
These steps were adapted from the ones written earlier in build.sh.
The trap invokes clean upon unsuccessful termination.
If there are a number of build files to clean, there is quite a significant pause from when an error occurs to when control is handed over to the user. This message indicates to the end-user what's going on during that time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please refer to the associated issue (#1) for more information. In summary, a cli tool
fota.shwas created to aid the end-user in setting up and building the BLE FOTA examples. The tool takes in as arguments the example, target board, mount point of target board, and toolchain.Closes #1