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

Bundled thirdparty #6863

Closed
rapgro opened this issue Oct 30, 2014 · 22 comments · Fixed by #6972 or #7953
Closed

Bundled thirdparty #6863

rapgro opened this issue Oct 30, 2014 · 22 comments · Fixed by #6972 or #7953

Comments

@rapgro
Copy link

rapgro commented Oct 30, 2014

Please provide build instructions for all the 3rdparty libraries etc.

In Fedora, distribution of prebuilt assemblies is not allowed. All has to be based on available sources, also for legal reasons.
https://fedoraproject.org/wiki/Packaging:Mono?rd=Packaging/Mono#Distributing_Prebuilt_Assemblies

@Mailaender
Copy link
Member

@rapgro
Copy link
Author

rapgro commented Nov 1, 2014

Thanks for the hint.

mono-nat is already in Fedora but orphaned. I guess it would need some love and interpolation.
https://admin.fedoraproject.org/pkgdb/package/mono-nat/

02.2012: "no upstream development for more than a year and no more need in fedora since monsoon is retired as well"
http://pkgs.fedoraproject.org/cgit/mono-nat.git/commit/?h=f18

@Mailaender
Copy link
Member

We can't migrate to Open.NAT yet as we are still on the .NET client profile 4.0 #5466 (comment).

@Mailaender
Copy link
Member

The SharpZipLib is not the version bundled with Mono, but the latest found in upstream. See https://build.opensuse.org/package/show/Mono:Community/sharpziplib for a package.

@Mailaender
Copy link
Member

I also plan to migrate on an upstream released version of OpenGL/AL/SDL C# bindings. #6893 See https://build.opensuse.org/request/show/260109 for an RPM package.

@rapgro
Copy link
Author

rapgro commented Nov 6, 2014

Thanks for the information. Does that mean Fedora should wait with the official package review till the next official release of OpenRA will be available? I would suggest so to avoid possibly doubled work effort, and we can continue to discuss the unbundling process here in this issue ticket.
Downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1159091

@Mailaender
Copy link
Member

I suggest to start packaging the https://github.com/OpenRA/OpenRA/tree/bleed/thirdparty CLI dependencies in Fedora already. SDL2-CS.dll is probably going away here and tricky for packaging and IP review because it mixed licenses, had no releases and included parts of other projects. So I suggest you do that last or if it takes longer than our release cycle skip it.

@Mailaender
Copy link
Member

See also the discussion at #5485.

@rapgro
Copy link
Author

rapgro commented Nov 19, 2014

So does that mean you will always support the official versions of libraries shipped in Fedora?

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

@pchote
Copy link
Member

pchote commented Nov 19, 2014

That shouldn't be a problem as long as the libraries are well behaved.

The main exception ATM is our version of Eluant, which relies on a couple of custom changes that I haven't attempted to merge upstream yet.

@rapgro
Copy link
Author

rapgro commented Nov 19, 2014

Sorry but I don't understand the comment about Eluant. You provide a README file that clearly states you are using concrete libraries from respective authors. Where is the hint that Eluant should be patched and please reference those patches?

@pchote
Copy link
Member

pchote commented Nov 19, 2014

The readme file references my Eluant fork, which has the openra-specific patches.

@rapgro
Copy link
Author

rapgro commented Nov 19, 2014

Okay, I did not see the already done fork. But that means trouble for me: Should I package the official Eluant or your fork or both? I can wait till the patches will be applied but that would mean a blocker for the review of OpenRA.

@rapgro rapgro changed the title Bundled 3rdparty Bundled thirdparty Nov 19, 2014
@rapgro
Copy link
Author

rapgro commented Nov 19, 2014

The Makefile does not support to install only the OpenRA assemblies. Please provide a new make option without the hard dependency to bundled dll files, probably by refactoring. That patch should be easy.

https://github.com/OpenRA/OpenRA/blob/bleed/Makefile#L324

@phrohdoh
Copy link
Member

In my opinion: Makefiles are for simplicity. If there are n more steps (or targets to invoke) then the whole point is moot.

@pchote
Copy link
Member

pchote commented Nov 19, 2014

It may be simpler for the fedora package to patch these lines out in the short term.

pchote added a commit to pchote/OpenRA that referenced this issue Nov 20, 2014
@Mailaender
Copy link
Member

We can do a new target install-dependencies. That should be no problem. I guess the main problem is to also link against those system libraries in the first place instead of the hard-coded ./thirdparty/*.dll location. https://github.com/OpenRA/OpenRA/blob/bleed/Makefile#L40

@Mailaender
Copy link
Member

@Mailaender
Copy link
Member

#7346 removes the thirdparty/windows directory. Now only Mac binaries are left.

@Mailaender
Copy link
Member

#7479 will remove the last Windows binary from the source tarball.

@Mailaender
Copy link
Member

This is not yet resolved completely.

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