beeware
file has different content between sources; ignoring x86_64 version
Describe the bug
Using a M1 mac platform, when packaging for Xcode backend I get these messages:
Merging app_packages.arm64... done
numpy/__config__.py has different content between sources; ignoring x86_64 version.
numpy/core/include/numpy/_numpyconfig.h has different content between sources; ignoring x86_64 version.
numpy/core/lib/libnpymath.a has different content between sources; ignoring x86_64 version.
numpy/random/lib/libnpyrandom.a has different content between sources; ignoring x86_64 version.
Merging app_packages.x86_64... done
Merging libraries...
Does this mean the app won't work for x64_64. platform? Is there a way to fix that? Thanks!
Steps to reproduce
run packaging command with Xcode target
Expected behavior
expect no error messages
Screenshots
No response
Environment
- Operating System: macOS Sonoma 14.3.1
- Python version: 3.11
- Software versions:
- Briefcase: 7682008b8a1357cbb83e6ff97cfb7cfce1f2f51c
Logs
Additional context
No response
There's nothing to fix here; the app will work fine.
Numpy is published as platform-specific wheels - there's an x86_64 wheel and an arm64 wheel. To produce a universal macOS binary, briefcase merges these two wheels into a single universal package.
However, there are some files that are different between the two platforms, and can't be automatically merged - those are the files that are identified in the log messages.
In this case, there's no problem - the files are headers and static libraries that aren't used at runtime. They exist purely for the benefit of other libraries to link against. There's a reasonable argument to be made that they shouldn't be in the wheel at all.
These messages are informational and worth interrogating, but they're not errors. If there was an error, Briefcase would stop, print a message in red, and would not produce output. In this case, you will have a successfully packaged app that should run.
Unfortunately, it's impossible to provide a categorical "this will work" answer for all packages. I happen to know these particular files are OK for Numpy because Numpy packaging is part of our test suite. However, I can't provide the same guarantee for every package on PyPI.
That said - it would be worth adding a note in the macOS platform quirks about this, and possibly linking to that document if mismatched files are found. The messages that are currently logged are "technically correct, which is the best kind of correct :-)" , but doesn't provide any actionable response.
Reopening as there is an actionable improvement we can make here - documentation and a linked error message improvement.