[build] Make raylib available in package managers #613

raysan5 · 2018-07-30T14:01:53Z

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

Currently supported package managers:

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

raysan5 · 2018-07-30T14:10:55Z

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

jubalh · 2018-07-30T14:14:32Z

@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 · 2018-07-30T14:23:09Z

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

define-private-public · 2018-07-31T05:09:45Z

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 · 2018-07-31T10:01:02Z

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 · 2018-08-19T06:53:05Z

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 #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 · 2018-08-19T16:02:06Z

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 · 2018-08-19T18:57:43Z

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 · 2018-08-25T16:35:40Z

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 · 2018-08-25T17:10:25Z

No worries at all. 😄

carlsmith · 2018-09-14T06:22:06Z

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 · 2019-04-05T02:33:28Z

One more: microsoft/vcpkg#5946

jubalh · 2019-04-05T09:50:40Z

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

wbrbr · 2019-06-02T19:51:42Z

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

raysan5 · 2019-06-02T20:01:21Z

@wbrbr oh! nice! is someone going to update it to latest release?

wbrbr · 2019-06-02T20:07:21Z

Yes the new maintainer should do it soon since it has been flagged as out of date. I can't give you more details because I don't know them haha

a3f · 2019-06-02T22:56:52Z

I am wondering if we should start incrementing SOVERSION every 2.x release to prevent applications dynamically linked against one raylib version from having a later, backwards incompatible, raylib loaded. Thoughts?

jubalh · 2019-06-03T09:07:34Z

I am wondering if we should start incrementing SOVERSION every 2.x release to prevent applications dynamically linked against one raylib version from having a later, backwards incompatible, raylib loaded. Thoughts?

I am saying this since years (on various issues here and on the chat) :-)

See:

a3f · 2019-06-04T14:22:37Z

Its also important to increase the major version number of the library version upon every ABI incompatible release (no need to increase general raylib major version just shared object major version number).

@jubalh, I've missed this comment of yours. I just noticed the discussion around breakage on minor versions. I am in favor of this. I would suggest that we start incrementing SOVERSION directly after every software release with the normal library versioning scheme unaffected.

raysan5 · 2019-06-04T15:11:42Z

I was thinking in a way to increment API version consistently with library version.

Considering API and ABI are very prone to changes, maybe we can just use RAYLIB_API_VERSION = 250 and increase that number aligned with 2.5.0. What do you think?

a3f · 2019-06-04T15:17:32Z

@raysan5 incrementing API version directly after a release would allow the git version to be installed alongside the released version and binaries linked against an old version or explicitly requesting the released version would continue to work.

If we increment before the release, this wouldn't work.

a3f · 2019-06-04T21:12:11Z

What we could do is set to 251 now, 260 on release and 261 directly after... ? (granted that 2.6.0 is the next version)

raysan5 · 2019-06-04T21:15:17Z

How often should we increase the revision number? I mean, 252-253-254...

a3f · 2019-06-05T06:55:16Z

@raysan5 What we absolutely want is for every release to have a different API version. A different API version for the git trunk is nice to have because issue reporters are often told to try the newest git snapshot, so we shouldn't accidentally break their already linked applications if they install from git.

Breakage will still happen, if you install an unreleased git snapshot, dynamically link, and come back later to install a newer version from git. But if you do that, we'll assume you're experienced enough to expect breakage and to deal with it.

To sum up:

Just before tagging the release:
- set software version to new version
- set API version to software version / 100
Directly after tagging the release:
- increment API version by one

Both commits can be done together. Thoughts?

raysan5 · 2019-06-06T09:28:45Z

@a3f ok, I understand, it looks ok this way.

VelocityIsntSpeed · 2019-07-02T01:39:18Z

AppGet for Windows is missing from the list.

elitepleb · 2019-10-08T14:26:01Z

any fans of alternate build systems here?
I'm looking for someone to finish this xmake package

raysan5 · 2019-10-08T15:34:15Z

@elitepleb oh! looks nice! :D

sudopluto · 2019-10-23T14:40:55Z

Might look at some of the opensuse packaging to make a fedora copr repo, no promises though.

raysan5 · 2019-12-04T10:11:07Z

raylib is already available in some package managers. I think this issue is not the best way to track those packages... Closing the issue.

raysan5 mentioned this issue Jul 30, 2018

[build] Make raylib available in package managers #401

Closed

5 of 10 tasks complete

a3f mentioned this issue Jun 4, 2019

build: increment API_VERSION after release #862

Merged

raysan5 closed this Dec 4, 2019

raysan5 / raylib

Sponsor raysan5/raylib

Join GitHub today

[build] Make raylib available in package managers #613

[build] Make raylib available in package managers #613

Comments

raysan5 commented Jul 30, 2018 • edited

This comment has been minimized.

raysan5 commented Jul 30, 2018

This comment has been minimized.

jubalh commented Jul 30, 2018

This comment has been minimized.

raysan5 commented Jul 30, 2018

This comment has been minimized.

define-private-public commented Jul 31, 2018

This comment has been minimized.

a3f commented Jul 31, 2018

This comment has been minimized.

QuLogic commented Aug 19, 2018 • edited

This comment has been minimized.

raysan5 commented Aug 19, 2018 • edited

This comment has been minimized.

justinclift commented Aug 19, 2018

This comment has been minimized.

raysan5 commented Aug 25, 2018 • edited

This comment has been minimized.

justinclift commented Aug 25, 2018

This comment has been minimized.

carlsmith commented Sep 14, 2018 • edited

This comment has been minimized.

myd7349 commented Apr 5, 2019

This comment has been minimized.

jubalh commented Apr 5, 2019

This comment has been minimized.

wbrbr commented Jun 2, 2019

This comment has been minimized.

raysan5 commented Jun 2, 2019

This comment has been minimized.

wbrbr commented Jun 2, 2019

This comment has been minimized.

a3f commented Jun 2, 2019

This comment has been minimized.

jubalh commented Jun 3, 2019 • edited

This comment has been minimized.

a3f commented Jun 4, 2019

This comment has been minimized.

raysan5 commented Jun 4, 2019

This comment has been minimized.

a3f commented Jun 4, 2019

This comment has been minimized.

a3f commented Jun 4, 2019

This comment has been minimized.

raysan5 commented Jun 4, 2019

This comment has been minimized.

a3f commented Jun 5, 2019 • edited

This comment has been minimized.

raysan5 commented Jun 6, 2019

This comment has been minimized.

VelocityIsntSpeed commented Jul 2, 2019

This comment has been minimized.

elitepleb commented Oct 8, 2019

This comment has been minimized.

raysan5 commented Oct 8, 2019

This comment has been minimized.

sudopluto commented Oct 23, 2019

This comment has been minimized.

raysan5 commented Dec 4, 2019

raysan5 commented Jul 30, 2018 •

edited

QuLogic commented Aug 19, 2018 •

edited

raysan5 commented Aug 19, 2018 •

edited

raysan5 commented Aug 25, 2018 •

edited

carlsmith commented Sep 14, 2018 •

edited

jubalh commented Jun 3, 2019 •

edited

a3f commented Jun 5, 2019 •

edited