Delete extra EmbraceObjCUtilsInternal module.modulemap file

[0xLucasMarcal]

Checklist

Remove extra modulemap file.

Swift Package Manager only searches for modulemap files for library targets inside the include/ folder.

This file is not being used anywhere and fails to build when using auxiliary tools like rules_swift_package_manager that translates SPM target description into Bazel BUILD files

• PR Description to summarize changes
• Add sufficient test coverage
• Read Contributing Guidelines
• Agree to Embrace CLA

[0xLucasMarcal]

@NachoEmbrace @ArielDemarco

[ArielDemarco]

Hey @lucasmarcal-faire! thanks for the contribution! Unfortunately, we cannot remove the module.modulemap from EmbraceObjCUtilsInternal as it's being used by the Project.swift file, which defines our project for Tuist during the .xcframeworks creation process.

To give a bit of context: Generating .xcframeworks directly from a Package.swift can be nearly impossible in many cases (we invested many hours trying to figure out an easier way to achieve this using the package definition or the underlying .xcodeproj that SPM creates). To work around this, we generate an .xcodeproj that closely resembles the Package.swift. However as you may know, SPM automates certain steps, like generating module maps, which we need to manually replicate using Tuist.

That being said, one potential solution is to adjust the script used for creating .xcframeworks (you can find it in ./bin/build_xcframeworks). You could modify it to generate the module.modulemap before running both tuist install and tuist generate, and then either remove it post-process or exclude it by adding the .modulemap to .gitignore.

[0xLucasMarcal]

Actually, in the Project.swift you are using the other one that is placed in the include/ folder
https://github.com/embrace-io/embrace-apple-sdk/blob/main/Project.swift#L221C55-L221C79

All the other references to the ObjcUtils target to include as a search path refer to its include/ folder.

Or is that something that happens under the hood?

[0xLucasMarcal]

Just in case, I ran the ./bin/build_xcframeworks, which succeeded with these PR changes.

Also, the entire structure of EmbraceObjCUtilsInternal.xcframework is preserved, with a modulemap that sets EmbraceObjCUtilsInternal.h as the umbrella header, with all other headers included in it.

[ArielDemarco]

Actually, in the Project.swift you are using the other one that is placed in the include/ folder https://github.com/embrace-io/embrace-apple-sdk/blob/main/Project.swift#L221C55-L221C79

All the other references to the ObjcUtils target to include as a search path refer to its include/ folder.

Or is that something that happens under the hood?

You're absolutely right! I'm not sure why there was duplication, but the module references are indeed as you mentioned.

I cloned the fork and tested the generated .xcframeworks in one of our test apps, and everything seems to be functioning perfectly. LGTM!

[ArielDemarco]

It seems the tests passed, but for some reason, the xcresulttool action (which is then used to upload the coverage) failed. Issue isn't related to the PR and/or changes in it (besides, the tests, as I mentioned, passed). I'll merge it.
Thanks @lucasmarcal-faire for the contribution!