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

Add NuGet support for macOS #161

Closed
eXpl0it3r opened this issue Jul 11, 2021 · 5 comments
Closed

Add NuGet support for macOS #161

eXpl0it3r opened this issue Jul 11, 2021 · 5 comments
Labels

Comments

@eXpl0it3r
Copy link
Member

eXpl0it3r commented Jul 11, 2021

The current NuGet packages don't support macOS.

I've spent quite some time getting this working, but have been unsuccessful with the RPATH/in-package dependency resolving.
This issue is a placeholder to keep track of this task.

See also #158

CSFML.2.5.2.nupkg.zip

@eXpl0it3r
Copy link
Member Author

This should be a good resource for figuring this out: https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling

@eXpl0it3r
Copy link
Member Author

For some reason I totally overlooked #151 which also has some hints for building on macOS

@eXpl0it3r
Copy link
Member Author

I finally understand the parts of the issue and thus probably the missing puzzle pieces:

  • Because we're using generic CSFML module names (e.g. csfml-graphics vs libcsfml-graphics.dylib), the search path doesn't include the .dylib suffix, despite the MS docs claiming to add those automatically.
  • The library search doesn't look inside the nuget package location and/or the dylibs aren't automatically copied to the output directory, so even of they are named correctly, they are not found.
  • The SFML dependencies (e.g. freetype as framework) aren't packaged with the nuget file and this can't be found.

Potential solutions:

  • Add an name resolution override function that correctly handles the naming per platform.
  • Look into the mechanics of how and when native library files are copied. Do they just need to match in name?
  • Consider linking SFML statically and include OpenAL32 in the nuget package

@eXpl0it3r
Copy link
Member Author

Well it took a lot of tinkering and adding some not so nice workarounds with rpath resolving, but it's finally working! 🥳

Please give the newly published package a try: https://www.nuget.org/packages/CSFML/2.5.2

@eXpl0it3r
Copy link
Member Author

Fixed with #185

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

No branches or pull requests

1 participant