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

Create CMakeLists.txt #90

Merged
merged 7 commits into from
Feb 28, 2024
Merged

Create CMakeLists.txt #90

merged 7 commits into from
Feb 28, 2024

Conversation

murillo128
Copy link
Contributor

This PR adds a CMakeLists.txt to be able to generate a static/dynamic library that can be used for projects not using cmake build systems (and therefore sigv4FilePaths.cmake directly)

By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.

@ydhuang28
Copy link

Thank you for your contribution! We'll take a look at it.

Copy link
Member

@ActoryOu ActoryOu left a comment

Choose a reason for hiding this comment

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

Could you help to fix the CI?
Besides that, only one minor comment from me.

Thanks.

CMakeLists.txt Outdated
$<BUILD_INTERFACE:${SIGV4_INCLUDE_PUBLIC_DIRS}>
$<INSTALL_INTERFACE:include/${PROJECT_NAME}>
)
target_compile_definitions(${PROJECT_NAME} PRIVATE -DSIGV4_DO_NOT_USE_CUSTOM_CONFIG )
Copy link
Member

Choose a reason for hiding this comment

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

IMHO, we shouldn't set this option by default. That should be optional for users.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with @ActoryOu here. this should be an active choice by users.

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 don't think I agree. The CMakeList.txt creates a compiled library, so we need the config file when we compile the library. Then we would need to distribute the binary, lib headers and the custom header, and include it again with building the final app.

AFAIK there is no way to include a custom include file dynamically when building the library. If the user is building the app alongside with the library (i.e. including the custom config file before including the sigv4 header), then it should be using the sigv4FilePaths.cmake instead.

If you want to control the values of the default config, we could add cmake configuration variables for controlling the individual parameters:

  • SIGV4_PROCESSING_BUFFER_LENGTH
  • SIGV4_MAX_HTTP_HEADER_COUNT
  • SIGV4_MAX_QUERY_PAIR_COUNT
  • SIGV4_WORST_CASE_SORT_STACK_SIZE
  • SIGV4_HASH_MAX_BLOCK_LENGTH
  • SIGV4_HASH_MAX_DIGEST_LENGTH
  • SIGV4_USE_CANONICAL_SUPPORT

Overriding logging should be better done as a method and not as a macro IMHO.

Copy link
Member

Choose a reason for hiding this comment

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

Could a middle ground here be to do what is done in the FreeRTOS-Kernel's CMakeLists.txt where the directory for the config file is checked?

A user that does not pass one in could then just be defaulted to having this option set?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

seems good to me

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 tried to provide a patch cloning the freertos kernel cmakelist.txt, not sure if this is what you expected. Could you review it, please?

@murillo128
Copy link
Contributor Author

murillo128 commented Dec 29, 2023

@ActoryOu I have disabled the spell checking on the CMakeLists.txt file for passing the CI, is this acceptable? It doesn't seem that the cspell has a language specific for cmake and adding DSIGV .cSpellWords.txt didn't seemed right

@murillo128
Copy link
Contributor Author

@ActoryOu could you take a look at this please?

@murillo128
Copy link
Contributor Author

@ydhuang28 @ydhuang28 any feedback on this? could you run the proof_ci workflow?

@@ -29,3 +29,4 @@ ignorePaths:
- 'docs'
- 'ThirdParty'
- 'History.txt'
- 'CMakeLists.txt'
Copy link
Member

@Skptak Skptak Feb 22, 2024

Choose a reason for hiding this comment

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

Why was this change needed?

EDIT: Sorry, had missed the conversation above link

There is already precedent to add CMAKE variables to the lexicons. I consider this worth the tradeoff of having more basic typos caught with a single command than separate commands/config files.

Copy link
Member

Choose a reason for hiding this comment

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

Running it locally I got this result:

# spellCheck
(node:22730) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
 1/38 ./CHANGELOG.md 281.05ms
 2/38 ./CMakeLists.txt 99.14ms X
/Users/skptak/repos/libraries/SigV4-for-AWS-IoT-embedded-sdk/CMakeLists.txt:35:53     - Unknown word (DSIGV)      -- PROJECT_NAME} PRIVATE -DSIGV4_DO_NOT_USE_CUSTOM_CONFIG
	 Suggestions: [sigv, SIGV, SDIV, DSIZE, DESIGN]

I would much rather add DSIGV to the .cSpellWords.txt than to exclude this file from all spell checks.

Copy link
Member

Choose a reason for hiding this comment

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

I agree with @Skptak. We should not remove CMakeLists.txt since there are only few violations which we need to add to cSpellWords.txt.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

seems fine for me, let me change it

Copy link
Member

@AniruddhaKanhere AniruddhaKanhere left a comment

Choose a reason for hiding this comment

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

Thank you for this change @murillo128. It looks good to me.

I am approving this PR.

@n9wxu n9wxu merged commit dbe5583 into aws:main Feb 28, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants