Conversation
|
Hi @lukaskollmer! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at [email protected]. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
|
OK, so if I understand correctly, |
|
correct; technically clang is warning about the fact that in addition to the command line definition there also is a i think eg |
|
@Cyan4973 thanks for merging this! do you have a rough estimate when the next release will be tagged? |
|
There's no ETA at this point. |
2 participants
fixes #3328 and #3892
issue at hand: the module.modulemap file was changed in #2953 and #3363 to contain a
config_macrosblock with a list of most of the macros that can be used to configure various aspects of how Zstd builds and behaves.however, clang's definition of a "config macro" is different from what one might instinctively assume a config macro to be: it only covers those macros that are exclusively passed via the command line (e.g. as
-DMACRO_NAME), and does not allow the macro be#define-d within the codebase, even if it wasn't defined via the CLI.zstd.h (and some other headers) currently contain blocks that conditionally
#definesome of the macros used to configure zstd, setting them to their default values if they are undefined (ie, if they haven't explicitly been set somewhere prior in the build process).this causes clang to emit a warning for each of these macros, unless the program using zstd explicitly specifies their values via the command line (which a program that wants to simply use the default value obviously would not do)
you can see e.g. here for an example of clang's / LLVM's usage & meaning of the term "config macro": they're effectively simple valueless macros that derive their meaning exclusively from the fact whether they are defined or whether they are not defined.