Ambiguous expansion of macro 'MAX'

[alestiago]

The installed sqlite3 Pod by this sqlite3_flutter_libs has a warning on line 31923 of sqlite3 is reporting Ambiguous expansion of macro 'MAX'

zBufNeeded = MAX(e2,0)+(i64)precision+(i64)width+15;

Screenshot

[simolus3]

I'm not sure if we can fix that. It's not our code (and we definitely want to keep shipping unchanged sqlite3 amalgamations from upstream).

You can add pod 'sqlite3', :inhibit_warnings => true to the target 'Runner' section of your Podfile to silence this warning. Unfortunately we can't add that anywhere because AFAIK this is only allowed in the root Podfile.
If you or someone with more knowledge about iOS builds has an idea for a workaround to explore, I'm happy to try that. I couldn't figure out how to silence the warning for users though.

[alestiago]

Hi @simolus3, I haven't yet tried silencing them. I'm wondering if we could include a documentation section on the docs that explains why and how to deal with these warnings that get introduced when using the package, what do you think?

I did some research, this is what I found when searching for Ambiguous expansion in the SQlite forum, this post "Weird warning on the Xcode/OSX" is quite aligned with what we're experiencing. There seems to be some thoughts from the forum users about it being an XCode or Clang issue.

These are the issues found by searching for "Ambiguous expansion" on the clang repository.

I haven't tried reproducing the warning solely with clang like sbooth user in the SQlite forum did.

[simolus3]

I've done some research and it turns out that it's only the clang from the macOS/iOS SDK that emits these warnings. A SwiftPM project (without Flutter) compiling sqlite3 works without warnings on my Linux machine, but emits the ambiguous macro warnings when compiled on macOS.

I'm wondering if we could include a documentation section on the docs that explains why and how to deal with these warnings that get introduced when using the package, what do you think?

That's definitely a good idea 👍, I'll add a section to the readme.

And with the migration to SwiftPM, this will luckily not be a problem anymore since we can just do this.