[build] Make raylib available in package managers #401

a3f · 2017-11-26T10:12:52Z

raysan5 · 2017-11-26T10:35:21Z

That would be a great addition!

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

jubalh · 2017-11-26T15:25:25Z

@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 · 2017-11-26T15:51:47Z

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

raysan5 · 2017-11-28T15:46:22Z

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 · 2017-11-30T14:52:04Z

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

raysan5 · 2017-11-30T16:01:41Z

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 9a75246

jubalh · 2017-12-01T14:07:07Z

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 · 2017-12-01T15:30:42Z

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

Optionally yes, to both.

jubalh · 2017-12-01T16:10:33Z

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

OvermindDL1 · 2017-12-01T16:43:33Z

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 · 2017-12-01T21:04:17Z

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 · 2017-12-01T21:32:34Z

@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 · 2017-12-01T21:39:50Z

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 · 2017-12-04T09:59:24Z

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 · 2017-12-04T10:46:03Z

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 · 2017-12-04T10:59:29Z

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 · 2017-12-04T11:05:59Z

@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 · 2017-12-09T11:47:22Z

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 · 2017-12-09T11:57:20Z

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

jubalh · 2017-12-09T14:08:40Z

@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 · 2017-12-09T17:03:21Z

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 · 2017-12-09T18:49:36Z

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

See raysan5#401 for the discussion.

See raysan5#401 for the discussion. Also bumps version number to 1.9.2 without the -dev, because neither ELF nor MachO like such a suffix. The -dev suffix will have to be restricted to the git tags.

raysan5 · 2018-01-24T13:55:42Z

Hi @Martinfx! Great work! What do you need to push freebsd port into raylib? Makefile changes? library changes? Maybe packages folder? Tell me!

Martinfx · 2018-01-24T14:11:29Z

Hi @raysan5 now only waiting for https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225402 if you will make new release i only update makefile in ports.

a3f · 2018-01-27T01:13:22Z

@Martinfx raylib.pc was malformed on FreeBSD. I've pushed a fix.
Also, OpenAL isn't needed anymore (it's not required for FreeBSD build at least)

Martinfx · 2018-01-27T12:21:28Z

@a3f I have my fork version with patches for Freebsd from https://github.com/Martinfx/raylib
if you have patch fix i havent problem here : https://github.com/Martinfx/FreeBSD-Ports/tree/master/raylib

a3f · 2018-01-27T12:56:25Z

I've created an issue about them: Martinfx/FreeBSD-Ports#1.

Martinfx · 2018-02-04T10:14:05Z

Hi @raysan5 could you make small release with my commits for freebsd package? (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225402) We have all but only waiting for new release. Thank you very much.

raysan5 · 2018-02-04T10:41:59Z

Hi @Martinfx, just let me do a couple of changes and I'll do a new "small" release. Changes:

Integrate and review @a3f proposed PR
Address [build] Please allow to use the pre-installed external glfw #453 and [build] Examples should build without the project being installed #452
Update version to 1.9.3
Integrate develop branch into master

a3f · 2018-02-04T11:15:28Z

@raysan5 The FreeBSD Bugzilla report uses CMake, so updating the Makefiles in #452 may not be a blocker.

raysan5 · 2018-02-04T11:55:06Z

ok, done. just waiting for CI checks and launching a new release (v1.9.3). Please, note this is a develop release and even being stable and usable there are still bugs to review and some features to add. It's just a step towards 2.0.

jubalh · 2018-02-05T13:09:23Z

@Martinfx can you not just add patches to your FreeBSD port instead of triggering a release? :)

Martinfx · 2018-02-05T18:23:54Z

@jubalh Yes, we can and is more work but better is all fixes in upstream :-)

jubalh · 2018-02-05T21:45:34Z

Noone doubts that fixes in upstream are necessary. But triggering a release for a downstream package is, in my opinion :)
Anyways I was not familiar with FreeBSD workflow and was just curious. Thanks for clarifying!

Martinfx · 2018-02-16T20:25:31Z

@raysan5 this is port for freebsd https://www.freshports.org/devel/raylib/ ! :-)

a3f · 2018-02-16T20:31:28Z

@Martinfx I was under the impression that OSS is used as audio backend on FreeBSD?

Martinfx · 2018-02-16T20:35:30Z

@a3f Yes is used.

a3f · 2018-02-16T20:36:59Z

Wouldn't the OpenAL prerequisite for the package be unnecessary then or do you get build errors?

Martinfx · 2018-02-24T13:19:01Z

@a3f Yes OpenAL prerequisite is redundant because is now sound backed mini_al. I will update port.

gen2brain · 2018-04-09T14:42:15Z

Gentoo ebuild is submitted here https://bugs.gentoo.org/652848 .

jubalh · 2018-04-09T15:21:43Z

@gen2brain nice. Thank you! Would you mind adding an 1.8.0 (stable) ebuild too besides having the git one?

gen2brain · 2018-04-09T15:33:34Z

@jubalh ebuild can just be renamed to e.g. raylib-1.9.4.ebuild and it will work, but only for -dev releases (until 2.0 is out). Stable 1.8.0 uses OpenAL, and don't have everything that is needed in CMake (some recent additions).

jubalh · 2018-04-09T15:49:29Z

I see. I always forget about the OpenAL.

gen2brain · 2018-04-09T19:45:02Z

@raysan5 Can you tag and build a new dev release ?

mandeep · 2018-07-30T00:21:29Z

@RDR8 @jubalh has there been any progress in building a debian package?

jubalh · 2018-07-30T08:19:51Z

@mandeep from my side: no. But also not actively working on it.

raysan5 · 2018-07-30T14:02:11Z

This issue became too long, I'm moving discussion to another issue for clearness > #613

a3f added enhancement This is an improvement of some feature help needed - please! I need help with this issue labels Nov 26, 2017

raysan5 changed the title ~~Make raylib available in package managers~~ [build] Make raylib available in package managers Nov 27, 2017

a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017

Add library versioning to CMake build system

b252acc

See raysan5#401 for the discussion.

a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017

Add library versioning to Make/CMake build systems

6c1bdcd

See raysan5#401 for the discussion.

a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017

Add library versioning to Make/CMake build systems

2ee9012

See raysan5#401 for the discussion.

raysan5 mentioned this issue Feb 4, 2018

[build] Could you please make a release? #457

Closed

vbarboza mentioned this issue Feb 17, 2018

[build] Yet another issue with Makefile and the documentation #472

Closed

iva0410217 mentioned this issue Jul 30, 2018

[text] Review LoadTTF() spritefont generation #375

Closed

raysan5 mentioned this issue Jul 30, 2018

[build] Make raylib available in package managers #613

Closed

9 tasks

raysan5 closed this as completed Jul 30, 2018

[build] Make raylib available in package managers #401

[build] Make raylib available in package managers #401

Comments

a3f commented Nov 26, 2017 • edited Loading

macOS

Windows

Linux

BSD

raysan5 commented Nov 26, 2017

jubalh commented Nov 26, 2017 • edited Loading

a3f commented Nov 26, 2017

raysan5 commented Nov 28, 2017

Martinfx commented Nov 30, 2017 • edited Loading

raysan5 commented Nov 30, 2017

jubalh commented Dec 1, 2017

OvermindDL1 commented Dec 1, 2017

jubalh commented Dec 1, 2017

OvermindDL1 commented Dec 1, 2017

jubalh commented Dec 1, 2017

OvermindDL1 commented Dec 1, 2017

OvermindDL1 commented Dec 1, 2017 • edited Loading

raysan5 commented Dec 4, 2017

a3f commented Dec 4, 2017

jubalh commented Dec 4, 2017

raysan5 commented Dec 4, 2017

wbrbr commented Dec 9, 2017

raysan5 commented Dec 9, 2017

jubalh commented Dec 9, 2017

raysan5 commented Dec 9, 2017

jubalh commented Dec 9, 2017

raysan5 commented Jan 24, 2018

Martinfx commented Jan 24, 2018 • edited Loading

a3f commented Jan 27, 2018

Martinfx commented Jan 27, 2018 • edited Loading

a3f commented Jan 27, 2018

Martinfx commented Feb 4, 2018 • edited Loading

raysan5 commented Feb 4, 2018 • edited Loading

a3f commented Feb 4, 2018

raysan5 commented Feb 4, 2018

jubalh commented Feb 5, 2018

Martinfx commented Feb 5, 2018 • edited Loading

jubalh commented Feb 5, 2018

Martinfx commented Feb 16, 2018

a3f commented Feb 16, 2018

Martinfx commented Feb 16, 2018 • edited Loading

a3f commented Feb 16, 2018

Martinfx commented Feb 24, 2018

gen2brain commented Apr 9, 2018

jubalh commented Apr 9, 2018

gen2brain commented Apr 9, 2018 • edited Loading

jubalh commented Apr 9, 2018

gen2brain commented Apr 9, 2018

mandeep commented Jul 30, 2018

jubalh commented Jul 30, 2018

raysan5 commented Jul 30, 2018

a3f commented Nov 26, 2017 •

edited

Loading

jubalh commented Nov 26, 2017 •

edited

Loading

Martinfx commented Nov 30, 2017 •

edited

Loading

OvermindDL1 commented Dec 1, 2017 •

edited

Loading

Martinfx commented Jan 24, 2018 •

edited

Loading

Martinfx commented Jan 27, 2018 •

edited

Loading

Martinfx commented Feb 4, 2018 •

edited

Loading

raysan5 commented Feb 4, 2018 •

edited

Loading

Martinfx commented Feb 5, 2018 •

edited

Loading

Martinfx commented Feb 16, 2018 •

edited

Loading

gen2brain commented Apr 9, 2018 •

edited

Loading