[build] Make raylib available in package managers

[raysan5]

This issue is a follow up of #401 . Just moved to a new issue flor clearness.

Currently supported package managers:

• macOS - Homebrew
• Windows - Chocolatey
• Windows - vcpkg
• Linux - openSUSE
• Linux - Arch User Repositories (AUR)
• Linux - Linuxbrew
• Linux - Gentoo
• Linux - Debian
• BSD - FreeBSD

If you are able and willing to help, you're welcome!

[raysan5]

Just noticed that openSUSE (@jubalh) and Arch (@nounoursheureux) are not updated to raylib 2.0, still 1.8.

[jubalh]

@raysan5 thats wrong. openSUSE Tumbleweed is updated to 2.0 on 24th July in the devel project https://build.opensuse.org/package/show/devel:libraries:c_c++/raylib. From then it goes through test rounds and landed on 28 July on Factory project. And from there will be shipped in the next snapshot.

[raysan5]

@jubalh oh, sorry! just look for it on the net and found that version... Thanks for the update! 👍 😄

[define-private-public]

I have experience doing debian packaging; I can offer my assistance for this. Though, I do want you to know that there are MANY different options to do this. Though this library is open source, I'd recommend creating a binary package (as they are a tad simplier to work with).

What's the status though on the CMake stuff? I know I helped with it a while back, but I'm really out of the loop on it. There does exist a command in CMake to generate the debian stuffs: https://cmake.org/cmake/help/v3.0/module/CPackDeb.html

[a3f]

There does exist a command in CMake to generate the debian stuffs

CI is configured to push a binary package (tarball) to the Github releases page whenever a new release is tagged, so we could use that. Anyone interested in trying to get it into the official repositories?

[QuLogic]

There are a couple issues making packaging a bit bothersome:

• The binary tarball is small, but it cannot be used to create a package; everything must be built from source.
• Using the snapshot tarball from GitHub will work but it has a lot of extra pre-built stuff in the release directory that we don't want. It seems like this sort of stuff should be on a separate branch or repo, or just left to the GitHub releases page.
• Would be nice to have a release with CMake: Major cleanup to support find_package(raylib) #608 since it fixes not only CMake issues, but building against the latest glfw release. (It does not cleanly apply directly to 2.0.0.)

[raysan5]

Now that we have CI and automatic release generation, maybe we can avoid release folder?

Probably build system needs to be updated to output to some default system folder?

@QuLogic Is it right if I publish a 2.1-dev release?

[justinclift]

A 2.1 or 2.1-dev release would be good from my PoV. It'd get the extra keyboard keys added today out "into circulation" faster. 😄

[raysan5]

releases directory removed in commit d6241d1

Makefile outputs to RAYLIB_RELEASE_PATH automatically on building.

Need some time for a 2.1-dev release...

[justinclift]

No worries at all. 😄

[carlsmith]

A package for Raspbian would be awesome.

The installation instructions for RaspberryPi in the wiki are broken (I'll open a separate issue soon).

EDIT: The instructions should work fine with the latest version of raylib (it failed on a dep that wasn't actually needed).

[myd7349]

One more: microsoft/vcpkg#5946

[jubalh]

Nice one! Already wanted to do the vcpkg myself :)

[wbrbr]

The Arch Linux package has been moved from the AUR to the official repository ! I am no longer the maintainer.