Closed jpbland1 closed 11 months ago
Just realized that my suggestion would break current builds that use
WOLFTPM_USER_SETTINGS
and don't have auser_settings.h
present. It would a quick fix with$ touch user_setting.h
but I get that we'd want to avoid that
This use case would only happen if trying to build wolfTPM without wolfCrypt and not using configure so it would require some type of build settings to be provided. Do you think this could be an issue for anyone in the "wild"?
Just realized that my suggestion would break current builds that use
WOLFTPM_USER_SETTINGS
and don't have auser_settings.h
present. It would a quick fix with$ touch user_setting.h
but I get that we'd want to avoid thatThis use case would only happen if trying to build wolfTPM without wolfCrypt and not using configure so it would require some type of build settings to be provided. Do you think this could be an issue for anyone in the "wild"?
The current patch is fine, I'd guess a very limited number of users with this setup. I was talking about this suggestion https://github.com/wolfSSL/wolfTPM/pull/285#issuecomment-1654521145 to always include user_settings.h
even with wolfCrypt when WOLFTPM_USER_SETTINGS
is defined
Why not move this outside of the
WOLFTPM2_NO_WOLFCRYPT
guard? That way users can have a separateuser_settings.h
for configuring wolfTPM instead of modifying their wolfSSL user settings. Same way we do wolfSSH, wolfMQTT, ...