Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve helper text around macOS third-party package merging #1973

Open
freakboy3742 opened this issue Aug 27, 2024 · 2 comments
Open

Improve helper text around macOS third-party package merging #1973

freakboy3742 opened this issue Aug 27, 2024 · 2 comments
Labels
enhancement New features, or improvements to existing features.

Comments

@freakboy3742
Copy link
Member

What is the problem or limitation you are having?

When deploying a dependency on macOS, platform-specific binaries are merged into a universal form. However, there are sometimes discrepancies between platforms in some files - especially .h, .a, and .py files used for configuration - e.g.,

image

These messages can usually be ignored - but it's not clear from Briefcase's output that this is the case.

Describe the solution you'd like

  • A reference in the macOS platform quirks that describes what these messages are warning about
  • If a problem file is found, a generic message message describing the problem should be printed, directing attention to the quirks page. i.e., output should be something like:
Thinning libraries in app_packages.x86_64... 
   ---------------------------------------- 100.0%
Merging app_packages.x86_64 ... done

Discrepancies were found between the x86_64 and arm64 versions of some files. 
The x86_64 version of the files will be used; you should confirm whether these 
discrepancies will cause a problem at runtime. For more details, see:

    https://briefcase.readthedocs.org/...

The following files are affected:

* numpy/__config__.py
* numpy/core/lib/libnpymath.h
...

For a really smooth user experience, it may be desirable to:

  • Allow for a user-specified "allowlist" of files that have known but acceptable discrepancies
  • Files that would be removed by the cleanup_paths marker should not be reported as a problem

Describe alternatives you've considered

We could potentially maintain an internal allowlist of known acceptable discrepancies. This would help avoid common packages (like numpy) raising this warning. However, that then puts the onus on us to do compatibility testing.

We could explicitly exclude some file types, like .h and .a, as these files are highly unlikely to be used at runtime. However, unlikely doesn't mean impossible.

Additional context

Arose through the discussion on #1972.

@freakboy3742 freakboy3742 added the enhancement New features, or improvements to existing features. label Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New features, or improvements to existing features.
Projects
None yet
Development

No branches or pull requests

7 participants
@freakboy3742 and others