Add config check automation tool for wolfSSL configure

[gojimmypi]

Description

The wolfSSL ./configure command has an extraordinary number of options and parameters that select target platforms, fine tune installation, optimize performance, select various features, and more. Managing and experimenting with the options can be a daunting experience, particularly for the new user.

This tool allows options to be specified in a more readable command file with comments. The output of the refresh script breaks out the resultant enabled and disabled features into more easily viewed summary files.

See the README.md for full details.

Fixes zd# n/a

Testing

How did you test?

There's no change to the underlying wolfSSL library. This is only a configuration assistance tool.

Run the from the config_check directory:

cd ./scripts/config_check
./refresh.sh

Observe files created in the config_check directory.

Checklist

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

[dgarske]

@jpbland1 is going to review and give this a try.

[kaleb-himes]

retest this please.

[gojimmypi]

Heads up I added the include.am to Makefile.am.

I also don't know why I was previously moving the the options.h. I changed that to a copy.

[gojimmypi]

jenkins retest this please

[jpbland1]

github says this branch is behind master, maybe merge the new changes and see if that fixes the build problem

[gojimmypi]

Replaced tee --append with tee -a. I don't have a Mac so I was unable to test on a Mac. Verified on WSL and real Ubntun VM.

Renamed the refresh script to config_check.sh and moved into scripts directory.

Now that I re-read that, @dgarske perhaps you meant literally the scripts/config_check directory? Not a problem if you'd like to isolate it all in a new subdirectory of scripts.

[gojimmypi]

@dgarske - done; moved into scripts/config_check on this PR ConfigCheck branch.

Should I try to squash commits during or after the PR review process? There are some rather petty ones cluttering up the history. Let me know the best practice for this.

[gojimmypi]

performed a

git reset $(git merge-base master $(git branch --show-current))
git push --force

to squash commits. Re-added config files & reopened this PR.

[gojimmypi]

Reopening this PR after using script to squash commits.

test with:

# prep 
git clone https://github.com/gojimmypi/wolfssl.git wolfssl_ConfigCheck_PR_Test --depth 1 --branch ConfigCheck
cd wolfssl_ConfigCheck_PR_Test 
./autogen.sh
cd scripts/config_check

# test
./refresh.sh

[gojimmypi]

updated readme, resync with upstream and squashed commits, reopened for review.

[kaleb-himes]

Initial thoughts on testing this out and reading the output:

1. Some of the comments seem hard-coded and if/when something is fixed will become obsolete

   • Example from cmd.txt -> --disable-md4 # !! this does not actually disable MD4 !! use NO_MD4 Observation: Down the road items may get fixed or changed... are the comments in cmd.txt going to automatically update or will someone have to manually maintain this long term? (Q: What is the potential technical debt associated with this solution?)

2. I've often needed to review things in the log which this solution seems to be getting at but my approach was to simply echo it to a file for review ./configure <options> > kaleb-config.log 2>&1 (NOTE: 2>&1 echo's stderr to stdout and all of stdout then gets directed to the file so everything is there when you need to review it) Q: Can you shed some light on what it is that this solution offers above and beyond a simple approach like the above? Q2: Is that additional offering worth the technical debt I suspect will result to maintain this and keep it up to date?

[gojimmypi]

@kaleb-himes I created this script mainly to have the ability to have a fully commented list of parameters to feed to the ./configure command. Sure, there are a variety of ways to compare the output. I personally like the separate lists of enabled and disabled features in separate files. In particular, I liked having the configuration history with my commits when it came time for memory footprint analysis.

Note that in my case, I was using it for an embedded project. So I was manually copying some generated settings from the ./configure to the project user_settings.h file. Keeping the ./configure parameters and result coordinated with my user_settings.h and code history was useful at the time.

Good point on the cmd.txt file; Your are correct that the sample as-is may not be appropriate, and in particular the comments. Do you have a suggestion for a good default configuration? Otherwise I can prune to something smaller with more obvious sample comments.

• edit:

Q: What is the potential technical debt associated with this solution.

Minimal to none of there's no specific comments in the example. I've removed some of the specifics.

Q: Can you shed some light on what it is that this solution offers above and beyond a simple approach like the above?

convenience of a ./configure command with comments on each of the parameters and readily viewed files of currently enabled and disabled features.

Q: Is that additional offering worth the technical debt I suspect will result to maintain this and keep it up to date?

I don't think there's much technical debt here, particularly if the example cmd.txt is kept simple. This is just a script to run the ./configure command and output files for a given project that I believe are easier to read than the full output.

[gojimmypi]

I appreciate the review and attention to detail. I've made some changes as suggested.

[wolfSSL-Bot]

Can one of the admins verify this patch?

[gojimmypi]

I've refreshed from upstream, squashed & re-added files; also fixed the line endings on the prior .gitignore that should have never been included (thanks @ejohnstown).

Let me know what needs to be done to get this one merged. Another issue came up regarding an embedded application needing particular settings in user_settings.h. I believe this script is a useful tool for seeing what gate macros change with the changes in command-line build options.

[gojimmypi]

Jenkins retest this please

[gojimmypi]

There are probably better tools available. I'm closing this lingering draft PR as I likely won't submit it in the near future.