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

Generate NuGet packages #160

Merged
merged 1 commit into from
Feb 20, 2019
Merged

Generate NuGet packages #160

merged 1 commit into from
Feb 20, 2019

Conversation

Davipb
Copy link
Contributor

@Davipb Davipb commented Dec 12, 2018

This pull request adds all of the machinery required to distribute SFML.Net as a NuGet package.
Once it is merged, every module will generate a full NuGet .nupkg complete with the proper metadata on build, and one simply needs to run PushNuGet.ps1 or pushnuget.sh to upload them to nuget.org.

Every individual module generates a NuGet package (SFML.Audio, SFML.Graphics, etc), and a
single empty package named SFML.Net references all modules as dependencies.
I have spoken with Sam, the owner of the SFML.Net Package on NuGet, and he is willing to transfer the Package ID to the owners of this repo.

Every module ships with its required CSFML and SFML native libraries for all platforms available on the official download page, and I have added extra scripts under src/Native to help build the native libraries for other platforms (mainly linux distros).

While you can verify that the .dlls and .dylibs on my repo are the same available officially from sfml-dev.org, I understand if you are wary of merging opaque executable binaries. I can remove those binaries from my repo and let you manually add them yourself, if needed.

Fixes #158
Fixes #154

@eXpl0it3r eXpl0it3r added the Feature New functionality or extending of an existing one label Dec 12, 2018
@joshward
Copy link

I tested this PR on a Window 64 machine and have come across a couple issues.

  • I can't build the project because the project files require a missing SFML.NuGet.props file. This file is ignored by the .gitignore file. So either you want to make sure that it's included in the project or it might be helpful to have documentation on how that should be filled out.
  • Once I added a dummy SFML.NuGet.props file, I noticed that the dotnet command you are running in your push scripts is dotnet publish, however I had to use dotnet pack to build the nuget packages. (I didn't test the push scripts just packing with the command locally.)
  • After packing the nuget packages, I noticed that the version number is defaulting to 1.0.0 and the Authors, and Owners info on the packages is using the default of <package id>. I assume that information is meant to be set in the SFML.NuGet.props file?

@Davipb
Copy link
Contributor Author

Davipb commented Dec 30, 2018

@joshward
Thanks for catching that, the missing SFML.NuGet.props is an integral part of the PR, and I didn't notice that it conflicted with an existing .gitignore rule.
All the issues you mentioned are resolved now that the file is included.

@p-m-j
Copy link

p-m-j commented Jan 3, 2019

If I run Native\build.win.ps1 I get the following error

CMake Error: The source directory "C:/Users/{{username}}/Dev/SFML.Net/src/Native/SFML" does not appear to contain CMakeLists.txt.

Is that also missing or did I do a thing incorrectly?

@Davipb
Copy link
Contributor Author

Davipb commented Jan 3, 2019

@rustybox
Did you clone the repository with its submodules? SFML and CSFML are included as git submodules, and the normal clone command doesn't initialize git submodules, leaving the folder empty.

Try running git submodule update --init --recursive, or cloning the repo with --recursive

@p-m-j
Copy link

p-m-j commented Jan 3, 2019

I did not, cheers

Built native modules, ran the following from repo root

$ dotnet build -c Release 

I end up with some nuget packages containing .net dll's and native dll's , seems good to me.

Is there a good reason to have the native dll's in the git repo, isn't that going to slow git down forever?

@Davipb
Copy link
Contributor Author

Davipb commented Jan 3, 2019

It's a timesaver and convenience for the contributors.

The alternatives would be:

  • Have the user provide them manually, which makes it one extra step harder to contribute to the project
  • Download them from sfml-dev.org at build time, which locks us to whatever platforms are available there, requires an internet connection to build the project, and slows the build
  • Build the native libraries during the build process, which requires installing a lot of extra tools to build the project (cmake, a C++ compiler, etc), slows the build a lot, and only builds the library for the current platform, making it necessary to copy files manually to generate a proper NuGet package

@p-m-j
Copy link

p-m-j commented Jan 3, 2019

Would it not be possible to have SFML.Net list another (for example) SFML.Net.Native nuget package as a dependency in the nuspec?

@Davipb
Copy link
Contributor Author

Davipb commented Jan 3, 2019

Sure, but then we just move the problem one package further - how would that SFML.Net.Native package be managed?

I suppose we could then leave that package out of the repository and let the maintainers manage it privately, but that would just create a bigger burden on them.

I can set up the packages like that if the maintainers prefer it that way, but the current setup is the most "painless" one in my view

@eXpl0it3r
Copy link
Member

eXpl0it3r commented Jan 7, 2019

Thanks a lot for this contribution and sorry that I haven't gotten back to you sooner.
I have been looking into how to best create NuGet packages myself, since I feel this is an integral part of the .NET world.

With SFML itself, we've added the dependencies as binaries to the repo, for convenience, because building the dependencies isn't always trivial and there's no fully established package manager for C++ (especially at the time SFML started out). I would not recommend to repeat this. It seems great at the beginning, but the longer it's there the more it blows up the repository size, stale dependencies, etc.

Since you seem to have the right experience, would it be possible to provide a similar NuGet setup for CSFML? Personally, I'd suggest to link SFML statically against CSFML, so you end up with just the CSFML DLLs plus OpenAL32.dll. But if you feel it should all be DLLs, then I'm fine with this as well.

Let me know, what you're willing to do and where I can help you with anything. 🙂

@Davipb
Copy link
Contributor Author

Davipb commented Jan 7, 2019

Sure, I can help with the CSFML packages. Should I set it up in this Repository, or in CSFML's repository (and make a pull request there)?

Also, a few caveats:

  • The compilation will have to be script-based (using the scripts from src/Native), since there's no easy way to integrate cmake and .NET Core projects
  • There's no easy way to deal with multiple platforms since they need to be built in different environments, so you'll have to copy the compiled files manually before publishing to NuGet if you want to support multiple platforms (Windows, Mac, Linux distros, etc)
  • The .NET Runtime requires that native libraries be dynamic, but I haven't found a way to statically link SFML while keeping CSFML dynamically linked on Linux, only on Windows. If you know how to do it on Linux, let me know.
  • I don't have access to a Mac computer, so I won't be able to make scripts for Macs.
  • NuGet supports Native C/C++ packages, but they have a different internal structure. So this CSFML package would serve only as a SFML.Net dependency, as it can't be used in Visual C++ projects.

@eXpl0it3r
Copy link
Member

  • Keep things local, so make the a PR for the CSFML repository.
  • Build scripts are fine, I however would not add them to the src directory, but maybe create a tools directory similar to how it's done in SFML.
  • Some manual copying is fine for now (could always potentially be automated in some way), as we're not integrating it into CI at this point.
  • Yes, the CSFML libs shall remain DLLs, only SFML should be integrated into CSFML via static linking. Not sure if the CSFML CMake file supports statically linking SFML on Linux, but if you have a specific question, I probably could help.
  • I should be able to provide builds, maybe even adjust your scripts. I will see what I can do here.
  • That's fine, we don't really recommend people to use CSFML directly, so there's no need for them to work in C/C++ project.

Thanks a lot 🙂

@Davipb
Copy link
Contributor Author

Davipb commented Jan 9, 2019

I've created PR #133 on CSFML and updated this PR to use the CSFML NuGet packages

@MarkWilds
Copy link

Looking good, cant wait for this to be merged into master.

@Davipb Davipb mentioned this pull request Jan 26, 2019
@Kaev
Copy link

Kaev commented Feb 1, 2019

Since the CSFML PR got merged, we could probably merge this aswell now.

@eXpl0it3r
Copy link
Member

eXpl0it3r commented Feb 13, 2019

Finally gotten around to test this.

Something seems to go wrong though, when I build the solution with VS 2017 it generates SFML.<module>.2.5.0.symbols.nupkg files instead of the *.snupkg as specified in the SFML.Module.props file. Any ideas why?

And then the script will try to publish it all things *.nupkg which include the symbols file, which NuGet then complains that the ID is already taken.

Should I build the package through the command line to begin with?

I'll try to investigate some more tomorrow, but maybe you have some insights in the meantime. 🙂

@Davipb
Copy link
Contributor Author

Davipb commented Feb 14, 2019

Hm, that's weird, my Visual Studio 2017 generates the *.snupkg files as it should.
Could it be that the .NET Core SDK you have installed doesn't support the newer .snupkg format?
You need at least version 2.2, and you can check your currently installed version with dotnet --version

@eXpl0it3r
Copy link
Member

Yep, I was running .NET Core 2.1 or so. Now I just need to get in contact with Sam w.r.t. the ID, but we also seem to have an issue where NuGet thinkgs SFML.System and sfml-system are too close, while it's fine with all the other modules. Maybe I'll need to check that with NuGet support. Otherwise it looks great and after some final checking this evening, I'll merge it. Thanks a lot again! 🙂

@p-m-j
Copy link

p-m-j commented Feb 14, 2019

Great work folks, HYPE for this!!

@eXpl0it3r
Copy link
Member

Haven't heard back from NuGet support yet. If worse comes to worst, do you think we could pick different IDs, like SFML.Net.System?

@Davipb
Copy link
Contributor Author

Davipb commented Feb 19, 2019

Well, I'd rather have the official packages with IDs that match the namespaces of the code itself, like other official packages, but sure, we could change it to SFML.Net.(Module) if NuGet doesn't budge.

@eXpl0it3r
Copy link
Member

Still no reply from NuGet support. I'm currently checking with @ctxnop if this could be worked around if I'm an owner of both IDs. If not, we probably need to change the .NET IDs.

@eXpl0it3r
Copy link
Member

It actually worked! All the SFML.Net packages have been published. 🎉
Thanks a lot to everyone involved and granting me access to the various IDs!
I'll make sure to merge this finally, later today. 🙂

https://www.nuget.org/packages/CSFML/
https://www.nuget.org/packages/SFML.Net/
https://www.nuget.org/packages/SFML.System/
https://www.nuget.org/packages/SFML.Window/
https://www.nuget.org/packages/SFML.Graphics/
https://www.nuget.org/packages/SFML.Audio/

@mikemac8888
Copy link

Really good timing. Just this morning I was looking for a way to use SFML with .net core. I installed and ran the examples on macOS with the following:

brew install sfml
brew install csfml
dotnet add package SFML.Net

At the top of the examples:

using SFML;

Thanks!

@dsoronda
Copy link
Contributor

Good job guys.

I hope that we could finaly close #158 and #161.

@eXpl0it3r eXpl0it3r merged commit 5ae4d3f into SFML:master Feb 20, 2019
@eXpl0it3r
Copy link
Member

Again, thanks a lot for all the work that went into this! 🎉

@ctxnop
Copy link

ctxnop commented Feb 20, 2019

You may also have to check with @xapdkop, he had forked my script for building nuget packages and it seems that he did a lot of work on them, updated them and so on. It seems that he provides nuget packages on his own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New functionality or extending of an existing one
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants