[build] Make raylib available in package managers

[a3f]

This would ease deployment quite a bit for users. The package should install a tagged release (e.g. 1.9.4-dev). If a more up-to-date or development snapshot can be requested, it should download the tarball for the newest master branch commit. See https://github.com/Homebrew/homebrew-core/commit/7f7b4bc0a604c8e6a9ccc117bde37245de61ff30 for an example.

macOS

• [X] Homebrew
• [ ] MacPorts?

Windows

• [ ] Chocolatey

Linux

• [X] openSUSE
• [X] Arch User Repositories (AUR)
• [x] Linuxbrew
• [ ] Gentoo
• [ ] Your Linux distro's package repositories

BSD

• [X] FreeBSD
• [ ] Your BSD's ports tree?

If you are able and willing to help, please tell.

[raysan5]

That would be a great addition!

Maybe @jubalh and @Martinfx could help on any of those?

[jubalh]

@a3f well, openSUSE has raylib in its official repository for quite some time already.

Edit: See https://github.com/raysan5/raylib/wiki/Install-on-GNU-Linux

OBS can also built Arch Linux, Debian, Fedora... packages if people are interested.

[a3f]

Good to know, amended the list. I should indeed have checked the Wiki first…

[raysan5]

Hi @Martinfx, sorry, my bad, I'm in the process of adding GLFW3 library as an additional raylib module (rglfw) and not uploaded the Makefile yet, I'm uploading it in the following days...

[Martinfx]

Hi @raysan5 i need maybe for port source code with freebsd patches (higher release ?) Thank you M.

[raysan5]

Sorry @Martinfx, I was also waiting for mini_al integration (replacing OpenAL Soft) and Makefile needs several changes... in the meantime just uploaded rglfw change in commit https://github.com/raysan5/raylib/commit/9a7524661fd31aef254abc1266132775aa4f0d07

[jubalh]

BTW: the meson build files use library versioning. I am not sure if the makefiles or cmake files do this too. But it is essential to have this if you want to be included in Linux distributions. For this reason openSUSE uses the meson build files in raylib. However it seems that the cmake files added later look very good and cover more, right? If those also use library versioning it might be worth using those and removing meson.

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).

[OvermindDL1]

I am not sure if the makefiles or cmake files do this too.

Optionally yes, to both.

[jubalh]

@OvermindDL1 why do we do this only optionally so far? Can you point me to the lines?

[OvermindDL1]

Raylib itself doesn't yet, but a PR could fix that, it's a couple lines added in both the Makefile and the CMakefile.txt.

[jubalh]

So with optionally you meant 'it is in theory possible', now I get it. Well, I am aware of that ;)

In any case, if several Linux distributions package raylib, and each uses a different build system, and some has features others don't that might not be an ideal case.

@OvermindDL1 if you know how to do it for CMake it would be nice to do it there, I would switch the openSUSE package to use CMake then instead of meson.

I am afraid that upon version changes it is more easy to forgot to increase the so nr if you have 10 places to do it.

[OvermindDL1]

@jubalh In https://github.com/raysan5/raylib/blob/master/src/CMakeLists.txt you'd want to add a new line of something like (I see that things like raylib_VERSION_MAJOR and raylib_VERSION_MINOR exist, no PATCH interestingly, but are unused, so what is going on there? I'll use them, but usually you'd pull it from a VERSION file or something):

set_target_properties(${RAYLIB} PROPERTIES
  SOVERSION "${raylib_VERSION_MAJOR}.${raylib_VERSION_MINOR}"
)

Then when the INSTALL build command is run then it will output the library with full version information in the linux standard way on linux along with symlinks to one with just the major and minor version, one to just the major version, and one to the name itself (on windows it will not do this, but it will bake the version number into the file metadata so windows tools can introspect it and so forth on each platform).

You would of course generally use a VERSION file with a full semver and just read it in normally though, be sure to change the right numbers as the API changes over time.

[OvermindDL1]

For note, there are SOVERSION and VERSION options, if both are empty then neither are used, if only one has a version number but the other does not then the empty one gets the same value as the filled on (so in the above case both SOVERSION and VERSION get the version), and if both are different then they are different. The differences between them is that SOVERSION is the API version, and should be a sumver (either 1, 2 or 3 parts) and is incremented as usual. VERSION is the Build version, becomes the build metadata information that is stored in, like, Windows library metadata chunk in the dll files. Usually they are both the same if using semver, they are generally only different if semver is not used. On Mac they are both used to store the 'current version' (VERSION) and the API-compatible version (SOVERSION).

This is all in the docs. :-)

EDIT: That CMakeLists.txt I looked at above is pretty messy, it could be substantially shrunk. Plus it seems to only have the option of compiling a static or a shared version of the library, it doesn't make both (I tend to opt for both to be generated by default with an option to disable one or the other). It looks like it needs a bit of an overhaul.

EDIT2: Also:

file(GLOB raylib_sources *.c)

This makes it so not all build scripts generated (most notable in visual studio) from picking up new files automatically without rerunning cmake to regenerate the project, where if the files are listed explicitly then it will update the project properly and automatically.

[raysan5]

That CMakeLists.txt I looked at above is pretty messy, it could be substantially shrunk. Plus it seems to only have the option of compiling a static or a shared version of the library, it doesn't make both (I tend to opt for both to be generated by default with an option to disable one or the other). It looks like it needs a bit of an overhaul.

@OvermindDL1, @jubalh, if you think CMakeLists.txt could be improved, you're welcome to send a PR, I'm not used to CMake...

About getting all .c files on src folder, keep in mind that some modules (rglfw) are only used on PLATFORM_DESKTOP, not others... maybe that can also be reviewed...

[a3f]

EDIT: That CMakeLists.txt I looked at above is pretty messy, it could be substantially shrunk. Plus it seems to only have the option of compiling a static or a shared version of the library, it doesn't make both (I tend to opt for both to be generated by default with an option to disable one or the other). It looks like it needs a bit of an overhaul.

Did you look at the CMakeLists.txt in the develop branch? Because that one can build both.

[jubalh]

You would of course generally use a VERSION file with a full semver and just read it in normally though, be sure to change the right numbers as the API changes over time.

Of course, that's why I said what I wrote above ;)

@OvermindDL1, @jubalh, if you think CMakeLists.txt could be improved, you're welcome to send a PR, I'm not used to CMake...

I am not used to CMake either, that's why I wrote the meson files (before the CMake ones were added). I only stated my concern that if you want to have raylib wants to get into distros, and they build from different build systems, and some build systems set a so version and others not, that might not be ideal. Additionally if they should increase the so version to the same number.

In any case, for now I will stay with the meson files, which I know, and take care of them.

[raysan5]

@jubalh agree that an unified build system that could work for most of distros would be the ideal solution... in the meantime:

In any case, for now I will stay with the meson files, which I know, and take care of them.

That's perfect for me.

[wbrbr]

I'm the maintainer of the AUR package :) Related question: what is the "recommended" build system for Linux ? I use make to build the AUR package (and it works), but I don't know if you plan to deprecate the Makefile in favor of CMake or Meson, if you do then I should switch.

[raysan5]

no plan to deprecate Makefiles, in my opinion, still the simpler and easy-to-use build system I know.

[jubalh]

@nounoursheureux AFAIK the are the most complete ones (also taking care of Android stuff etc). But I think they don't use library versioning. Wich Arch should use. Meson does this.

[raysan5]

Is it possible to add library versioning in some way to plain Makefiles?

Maybe something like:

RAYLIB_VERSION_MAJOR=1
RAYLIB_VERSION_MINOR=9

[jubalh]

@raysan5 it's possible. But I have never done it, sorry can't help with it :/

[a3f]

The way I understand it, we need output a libraylib.1.9.1.so with an API version (1.0.0) embedded (SONAME on ELF) and symlink it to bothlibraylib.1.so and libraylib.dylib and install all three.

Here 1.9.1 is the build version and 1.0.0 is the API version with which it is backwards compatible.

I opened pull request #417 that does this.

[jubalh]

https://github.com/raysan5/raylib/issues/293 was the original issue asking for library versioning.

At https://github.com/raysan5/raylib/blob/master/src/meson.build#L21 I already put the ABI version to be 1.8.0. I used the same as the projects version at that time. Maybe I should have started with 1.0.0, though it makes not much difference, except that it will be higher than the projects version soon.

The version of raylib is defined here https://github.com/raysan5/raylib/blob/master/meson.build#L1

I propose CMake and Make file library version should be set to what it is in meson now. I agree starting at 1.0.0 would have been another option, but now it is already released with 1.8.0, so we should increase that when ABI incompatible changes occur (meaning https://github.com/raysan5/raylib/blob/master/src/meson.build#L21 in meson).

[a3f]

My SUSE Tumbleweed tells me:

$ rpm -ql raylib-devel | grep '.so$' | xargs objdump -p | grep SONAME
  SONAME               libraylib.so.1

Doesn't that mean, the ABI version is 1.0.0 for Meson?

[raysan5]

@a3f @jubalh Thank you very much for working on this improvement.

Latest raylib official release is 1.8.0 but lots of changes are being done in develop branch so we agreed with @a3f to tag that branch as version 1.9.x-dev, useful for automatic releases generation.

As said, lot's of changes are being made in raylib develop branch and most probably next raylib official version will be raylib 2.0, I imagine at that point versioning problem will be solved.

[raysan5]

By the way @jubalh, now with added versioning, would it be possible to unify the build system with CMake or Makefile for openSUSE Linux distro instead of meson?

[jubalh]

@a3f yes soversion 1.

ls /usr/lib64/libraylib.so*
/usr/lib64/libraylib.so    /usr/lib64/libraylib.so.1.8.0
/usr/lib64/libraylib.so.1

raylib project version can be: 1.8.0, 1.9.0, 1.9.1, 2.0.0... But so name version (also called library versioning) should increase major version upon every ABI incompatible change.

I used version tag in src/meson.build. According to meson docu if I don't set soversion explicitly it will be taken from there.

EDIT: @a3f actually I thought it will take 1.8.0 as soversion only now I read in docu that the first part will only be taken.

[jubalh]

By the way @jubalh, now with added versioning, would it be possible to unify the build system with CMake or Makefile for openSUSE Linux distro instead of meson?

Certainly! Once the release is ready I will package raylib using Make. Probably will compile a bit slower than meson but thats no problem (especially for enduser of package).

I am all for that, it will decrease maintaining needs.

[jubalh]

Maybe this is a good read to understand the whole thing: http://ometer.com/parallel.html

So it's not so much about people who want to get latest raylib and develop with it. But more regarded to a scenario where already some games with raylib are out.

Game1 uses an old version which might have a function for collission called checkCol(). Game2 uses latest raylib in which it has been renamed to checkCollision().

Game1 developers didn't update their code for latest raylib. But we want both to be runnable, even without static compilation.

So Game1 can dynamically link to raylib version X and Game2 to version Y.

Since so far AFAIK there are not raylib based games in openSUSE (or in any other distro), there are no problems here yet anyway.

Just preparing for the future success of raylib ;)

[a3f]

I can't follow, sorry. How is project version for you different from library version? I assumed project version is "build" version and library version is compatibility/soname version.

[jubalh]

Yes terms are a bit awkward here. https://autotools.io/libtool/version.html Short: In https://github.com/raysan5/raylib/pull/417 you could remove meson.build and src/meson.build. Your CMake does all the stuff now :)

[raysan5]

Sorry for all the version confusion, probably my fault, when started raylib didn't think about it carefully, it only pretends to be a weekend project to teach game programming basis in an easy way. I'd have never imagined it would grow SO much (neither imaged I would invest thousands of hours of my life... :P).

Learned a LOT during this process... and keep learning new things everyday! That's amazing! :D

Hopefully current versioning scheme will work for now.

[RDR8]

@jubalh, could we leverage Open Build Service to raylib's advantage in some way? I'm not very familiar with OBS. To me, right now, it's simply an alternate way to get a binary. I don't suppose any binaries from there could end up in another distro's repository? Adding an additional link from the main Installation wiki might help a few people until someone addresses the Debian and Fedora elephants. Autotools?

Identifying specific targets seems like a priority, if mostly user-driven. I think I remember you stating that it takes years to get into Debian stable. Is that strictly necessary if we wanted to target Ubuntu 18.04 or Raspbian? I get that we want to be as far upstream as possible, but are there good options in the meantime? Has anyone even tried building on Fedora?

@raysan5 We see you (%

[RDR8]

Preparing a Debian package.

• [x] Document all of the following: More detail here ...

• [x] Chart a course to Debian Stable starting with Raspbian.

• [ ] Identify distribution packaging requirements. Not sure about included binaries. See #387

• [ ] Identify and configure required tooling. debhelper family and others.

• [ ] Model, unify and replicate the make and cmake implementations. Both make and cmake are supported by Debian packaging tools. @raysan5 It seems possible to put all of the additions in a debian/ subdirectory. More clutter ... but the existing implementations wouldn't be modified much, if at all. It's also possible to just branch and package out-of-tree with no additions to your source at all.

• [ ] Select package contents and sane compile-time defaults. Who is the target user? *What happens if a dev wants access to a different graphics API etc ... ? Refer to this comment from @jubalh. Additionally, a raylib-dev package could resemble the Windows/Notepad++ setup with pre-configured projects for Geany or other IDE. Some work with Code:Blocks is described in the wiki. For now, just working on a simple shared libraylib.so from the current 1.9.1-dev release.

• [ ] Build and test deb package.

• [ ] Submit to target distribution.

• [ ] (maintain(maintain))

Or ... go right to the market

Generate debs and rpms on OBS and distribute them directly from itch.

Also, some games from there use custom scripts or something like the Loki installer. Anyway, I kind of like the idea of leveraging OBS. @jubalh Is there anything about using it that prohibits commercial use? As a user, I'm comfortable interacting with itch. @raysan5 Do you get much activity there?

Please advise.

[jubalh]

could we leverage Open Build Service to raylib's advantage in some way?

OBS can build packages for Arch, CentOS, RedHat Enterprise, Fedora, Debian, Ubuntu, openSUSE. It won't show up in the distribution officials repository, the users will have to add that specific repo themselves (like Ubuntu PPA). CentOS, RH, Fedora, openSUSE all use rpm, so we just need one spec file, distributions differ however slightly in macros used etc so we need someone to write one that works for all of them. To build Arch packages we need a PKGBUILD, and for Debian/Ubuntu their stuff.

I think I remember you stating that it takes years to get into Debian stable. Is that strictly necessary if we wanted to target Ubuntu 18.04 or Raspbian?

It depends of the time. The current Debian stable is called "Stretch" and was released June 17th 2017, so not too long ago. The one before was released April 25th 2015. So you see, if you want to have it in Debian stable..you need to wait until a new Debian stable comes out. So maybe in 2 years ;)

However you can create a deb package yourself, submit it into Debian unstable if you find a sponsor, then wait a coupe of days and it will be in Debian testing. From there Ubuntu will automatically pull it.

Again it will not be in Ubuntu 'stable' until they do a new release.

Is there anything about using it that prohibits commercial use?

Sorry, I don't feel qualified to make any statements about legal stuff.

[jubalh]

So for example there is the XMPP client dino, in their wiki you can see that they use OBS to build packages for several distros.

Currently they use this as their official way to distribute their package.

As a test I created home:jubalh:raylib/raylib project on OBS. I adapted the spec file so now it builds rpm packages for: openSUSE Tumbleweed, Fedora 27 and Fedora Rawhide. I added the PKGBUILD from the AUR, too. As you can see it doesn't build for openSUSE Leap 42.3 because glfw version >= 3.2 isn't available there. And it doesn't build on Arch because it seems glfw is not in their Extra repository. Maybe there is a way to add more repos and have it build though.

In any case, I think this is a great way to build packages for many distributions. It's also good if you have knowledge/manpower and want your packages available for several distros as soon as possible after you release it.

However, I think in the long term it's better to bring things into the official repositories of the individual distributions. It would be best to find a volunteer, package maintainer in each of those distros, and let him/her package and maintain it there.

So either raylib has just to get big enough so many people use it, and maintainer starts to package it because they need it. Or we find a raylib fan who happens to use distro X and is willing to maintain it there. Or we learn all the skills needed and do it ourselves.

It seems the second option already happened for Arch and openSUSE.

BTW: Getting the package into Fedora should be fairly easy, as you can just use the spec file I already wrote ;)

In any case, if you want to have access to the test repo I created and decide to use it as a test ground, or to build packages quickly their so users can get it... just let me know.

[raysan5]

Wow, lot of information, I see I'm very noob on packages distribution...

Is there anything about using it that prohibits commercial use?

If you mean raylib, I'm not an expert on licensing, but the library itself and ALL the secondary libraries (mostly header-only libraries) are under zlib/libpng, MIT or public domain licenses. So, raylib can be used for commercial use. The only concern is public domain libraries, some countries like Germany seem to not recognize that kind of license... but not an expert on the field...

As you can see it doesn't build for openSUSE Leap 42.3 because glfw version >= 3.2 isn't available there. And it doesn't build on Arch because it seems glfw is not in their Extra repository. Maybe there is a way to add more repos and have it build though.

Current develop branch already includes rglfw module that embedds GLFW library, that way, we avoid that external dependency.

It seems the second option already happened for Arch and openSUSE.

Many thanks for your time and your hard work on that!

[RDR8]

Many thanks, indeed! I'm encouraged to take on Debian packaging not only to help distribute raylib but for the skills you speak of. @jubalh I appreciate your input. Bear with me.

To my second, slightly off-topic, idea...

Generate debs and rpms on OBS and distribute them directly from itch.

This additional strategy seems efficient in the short run and targets a popular existing channel. If @raysan5 is interested in having a penguin logo up in the store, I will most definitely work to advance that goal. A cursory glance at the OBS portal shows that OBS itself uses the GPL. My imaginary concern is the possibility of a restriction on products of the service coming into play when someone pays for raylib on itch, not the raylib license itself. Anyway, I'll learn. Thanks again.

[RDR8]

Hey, uh... I just noticed the 1.9.1 Releases. Couldn't you make those binaries available on itch?

I'm still on board for targeting Debian and am proposing three debs from the current Release tarball. raylib, with just the library for playing games, raylib-dev with headers, and something like a raylib-pro meta-package mimicking the Windows version with sources and associated tools. Having something ready for raylib 2.0 seems sensible.

Another easy way to increase your exposure is, as jubalh suggests, to direct people to OBS the way dino does. Doing it this way utilizes one of Linux' best features. It gets updates automatically with normal system updates just as if it came from the distribution repository.

Anyway, raylib is easy enough to get and build today for people who already know how to use it but, as per the OP, manual installation and minimal* Mac/Linux/BSD support are bottlenecks to on-boarding budding GNU developers. Consistent availability and feature parity with the Windows build might go a long way toward building that community.

Compared to the downright luxurious Windows version! *

[define-private-public]

Do you still need help with Debian/Ubuntu?

[RDR8]

Right now I'm set up for a first run through debian/* on Raspbian but don't have good files yet. The intention is to follow on with the Cmake build system. Thanks! btw. I'm probably overthinking it but you can follow my progress here. However, I'm kinda slow so if you want to jump ahead in your own way or just correct my thinking, feel free. I guess once we have a debian folder, anything goes. I am curious if @raysan5 is amenable to putting the packaging stuff into the raylib source tree? Seems like it, but since I don't know what I'm doing, I'm just working over on my fork.

[raysan5]

I am curious if @raysan5 is amenable to putting the packaging stuff into the raylib source tree?

Actually, I would like to keep the source tree as clean as possible... but we can try to find a clean solution for that, maybe a packages folder?

[define-private-public]

@RDR8 Wait? Are you working on raspbian specific packaging first before Ubuntu/Debian? Or did you get the later one done already?

@raysan5 I'd vote for that. We could then put a straight up Makefile or shell script in packages/ so anyone can write make deb or make rpm to auto build the packages for that platform.

For these, are you going to be building the dynamic versions of the libraries?

[RDR8]

My preference is to develop on Raspbian so yeah I'd like to do it first. Not sure what the Cmake status of RPI is, so I'll need to look at that. I think the platform is a great place for those, like me, learning C so I'm focusing on it. The any architecture tag is an important goal. Once I get going, I can jump over to Raspberry Pi Desktop for PC or Ubuntu and go from there.

Debian packaging seems to require a top-level debian/ dir. It's the single point of entry and everything related is below debian/ . deb tools work on top of make, cmake, or whatever tools are in use. None of the existing code is touched and additions are constrained to the debian/ folder. Certainly less intrusive than either make or CMake. The alternative is for the maintainer to take it out-of-tree, which isn't very reliable or efficient. I'll put something together in the next few days and you can take a look.

Yes, I figured building a shared libraylib is the first logical step. The headers would be in another -dev package. Distributing the examples and games in separate packages seems to follow Debian practice as well. A raylib meta-package with all the examples and games as well as Linuxy IDE project files and tutorials similiar to the Windows version would be awesome.

Following #387, as the resolution there is a dependency.

[define-private-public]

Gotcha. I've done a fair share of .deb packaging in the past year. If you need some help, I can assist. IMO, you might want to start with full Ubuntu/Debian packaging, then work down to any Raspbian specifics, but do what you want to do.

[RDR8]

Thanks! I think you're absolutely right about the starting point. I could/should be focusing on Debian since it's the furthest upstream. Hopefully, the Pi-specific stuff won't be too bad. It's mostly making sure that the base CMake build is working. I have not considered the implications of cross-compilation yet.

I would definitely appreciate some code review at a minimum. I'll post a branch here as soon as I can.

[RDR8]

Debian packaging seems to require a top-level debian/ dir.

Actually, I would like to keep the source tree as clean as possible... but we can try to find a clean solution for that, maybe a packages folder?

So far, I'm not seeing a debian/ directory in the git source trees of common software that I normally get from distro repositories. It looks like branching, then packaging is the way. Anyone have an informed opinion?

[define-private-public]

I've seen it before. Both in the master branch, and a special debian branch that contains, well, the debian package specific files. It's also possible they might be using a tool such as git-buildpackage which can automate the debian/ creation and building process.

[jubalh]

Some projects use it, but not mandatory at all. @RDR8 if you want to create the deb please read through: https://wiki.debian.org/Packaging And joining #debian-mentors in OFTC might be of help.