fix(cli): add cSettings support for compiler flags in generated Package.swift

[OS-ruimoreiramendes]

Parse compiler-flags from plugin.xml and generate cSettings in the SPM Package.swift.

Note: this PR will likely conflict with RMET-5159 (#8443) in the generateCordovaPackageFile function, as both PRs declare const sourceFiles in the same else block. Easy to resolve.

Reference: https://outsystemsrd.atlassian.net/browse/RMET-5161

[alexgerardojacinto]

Minor: I think the PR title should be fix(cli):...

[alexgerardojacinto]

@OS-ruimoreiramendes could you provide instructions on how to test this?

[OS-ruimoreiramendes]

@OS-ruimoreiramendes could you provide instructions on how to test this?

Any plugin with compiler-flags defined on its <source-file> elements in plugin.xml should work for testing. In my case I tested this with the Ciphered sample app using the source code from a MABS 12.1 build, but I also created a fresh Capacitor app to make sure the Cordova plugins used in the Ciphered app work in a plain Capacitor setup as well. This has been the setup I've been using to test all the changes across the PRs I have open for capacitor/cli.
The easiest way to test is probably using the source from a MABS 12.1 build, but I can share the app source with you if needed. Note that for dependencies to resolve correctly, the other open PRs I have for the CLI will also be needed.

[jcesarmobile]

Since it only handles compiler flags starting with -D, might be good to warn when there are compiler flags that don't get added, as if those flags are needed and are not added (and can't be added since most are unsafe), will most likely lead to the plugin not compiling, in example compiler-flags="-fno-objc-arc" is relatively common in old plugins and it's unsafe, so we can't add it, but the code won't compile without it, so a warning will give a hint.

[OS-ruimoreiramendes]

Since it only handles compiler flags starting with -D, might be good to warn when there are compiler flags that don't get added, as if those flags are needed and are not added (and can't be added since most are unsafe), will most likely lead to the plugin not compiling, in example compiler-flags="-fno-objc-arc" is relatively common in old plugins and it's unsafe, so we can't add it, but the code won't compile without it, so a warning will give a hint.

will add a warn message for compiler flags that don't get added

[jcesarmobile]

Why do you make such big refactor when the PR was already approved?

iosVersion should be get inside writeGeneratedPackageSwift, not a param.
headersText should be get inside writeGeneratedPackageSwift, not a param.

If none of the compiler flags is one of the "safe" ones and none get added to the cSettings it ends up with an empty cSettings array, in that case there shouldn't be cSettings at all.

If the compiler flag is -fno-objc-arc we are copying the files to a separate folder, that shouldn't be done if using SPM, otherwise the file will be missing from the package.

Also in the warning maybe use might instead of may as it express lower probability and we don't really know if it will fail to build or not.

[OS-ruimoreiramendes]

Why do you make such big refactor when the PR was already approved?

iosVersion should be get inside writeGeneratedPackageSwift, not a param. headersText should be get inside writeGeneratedPackageSwift, not a param.

If none of the compiler flags is one of the "safe" ones and none get added to the cSettings it ends up with an empty cSettings array, in that case there shouldn't be cSettings at all.

If the compiler flag is -fno-objc-arc we are copying the files to a separate folder, that shouldn't be done if using SPM, otherwise the file will be missing from the package.

Also in the warning maybe use might instead of may as it express lower probability and we don't really know if it will fail to build or not.

I follow the same approach you suggested on #8445 (comment). However, thinking about it more carefully, it might not have been the best idea to do this refactor here after the PR was already approved.
I'm considering reverting this last commit and instead applying the same pattern #8445, where you first flagged it. Once that PR is merged, we can carry that same logic over here for the cSettings part naturally.
Regarding the params, I'll fix those on the #8445 PR. Sounds good?

[jcesarmobile]

I prefer to finish this one since I already approved it, but address the latest comments I made.

[OS-ruimoreiramendes]

I prefer to finish this one since I already approved it, but address the latest comments I made.

Done, take another look when you can.

[jcesarmobile]

I've tested and the unsafeFlags actually work when the packages are local, but since for Cordova plugins they are added per file rather than for the whole plugin and it's not desirable to add things such as -fno-objc-arc to the whole plugin and for us supporting it it would require to put the files in separate targets (as we do for CocoaPods), so let's not do it for now, but keep it in mind in case users report it as a problem.