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

Sources of non-upstream third-party dependencies #524

Open
pandas-a11y-11 opened this issue Mar 13, 2024 · 1 comment
Open

Sources of non-upstream third-party dependencies #524

pandas-a11y-11 opened this issue Mar 13, 2024 · 1 comment

Comments

@pandas-a11y-11
Copy link

Is your feature request related to a problem? (optional)

Impossible to reproduce clean build from sources without using pre-compiled binary files, e.g. opencv sources actually used in build are nowhere to be found and attempts to use the upstream versions lead to Weasis build system complaining that opencv can't be found.

As per this comment #175 (comment) the opencv fork that Weasis requires seems only available as a binary.

It complicates building from source (instructions for that option are not provided in documentation).

Description of the new feature/enhancement

Would it be possible to provide full sources for bundled dependencies that differ from upstream sources? Will there be support provided for building Weasis from source, as provided in this repository?

Proposed technical implementation details (optional)

No response

Describe alternatives you've considered (optional)

No response

Additional context (optional)

No response

@nroduit
Copy link
Owner

nroduit commented Mar 14, 2024

If there's a problem with the current Weasis build, please describe it in detail.

Building the native part is not trivial and requires a system for each architecture. In addition, binaries are statically compiled with a range of systems to cover all systems still officially supported.

The current packaging process builds the weasis-native.zip package, from which installers can be built easily for any system and architecture. This is rather a simplification for users, as asking them to build the native part is not desired and I can't assume support for it. The situation could be different if there were experts who could contribute to the common effort on this development with precise objectives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants