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

[build] Make raylib available in package managers #401

Closed
5 of 10 tasks
a3f opened this issue Nov 26, 2017 · 83 comments
Closed
5 of 10 tasks

[build] Make raylib available in package managers #401

a3f opened this issue Nov 26, 2017 · 83 comments
Labels
enhancement This is an improvement of some feature help needed - please! I need help with this issue

Comments

@a3f
Copy link
Contributor

a3f commented Nov 26, 2017

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 Homebrew/homebrew-core@7f7b4bc for an example.

macOS

Windows

Linux

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

BSD

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

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

raysan5 commented Nov 26, 2017

That would be a great addition!

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

@jubalh
Copy link
Contributor

jubalh commented Nov 26, 2017

@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
Copy link
Contributor Author

a3f commented Nov 26, 2017

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

@raysan5 raysan5 changed the title Make raylib available in package managers [build] Make raylib available in package managers Nov 27, 2017
@raysan5
Copy link
Owner

raysan5 commented Nov 28, 2017

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
Copy link
Contributor

Martinfx commented Nov 30, 2017

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

@raysan5
Copy link
Owner

raysan5 commented Nov 30, 2017

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
Copy link
Contributor

jubalh commented Dec 1, 2017

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
Copy link

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

Optionally yes, to both.

@jubalh
Copy link
Contributor

jubalh commented Dec 1, 2017

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

@OvermindDL1
Copy link

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
Copy link
Contributor

jubalh commented Dec 1, 2017

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
Copy link

@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
Copy link

OvermindDL1 commented Dec 1, 2017

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
Copy link
Owner

raysan5 commented Dec 4, 2017

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
Copy link
Contributor Author

a3f commented Dec 4, 2017

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
Copy link
Contributor

jubalh commented Dec 4, 2017

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
Copy link
Owner

raysan5 commented Dec 4, 2017

@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
Copy link
Contributor

wbrbr commented Dec 9, 2017

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
Copy link
Owner

raysan5 commented Dec 9, 2017

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

@jubalh
Copy link
Contributor

jubalh commented Dec 9, 2017

@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
Copy link
Owner

raysan5 commented Dec 9, 2017

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
Copy link
Contributor

jubalh commented Dec 9, 2017

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

a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017
a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017
a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017
a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017
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.
a3f added a commit to a3f/raylib that referenced this issue Dec 10, 2017
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
Copy link
Owner

raysan5 commented Jan 24, 2018

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

@Martinfx
Copy link
Contributor

Martinfx commented Jan 24, 2018

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
Copy link
Contributor Author

a3f commented Jan 27, 2018

@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
Copy link
Contributor

Martinfx commented Jan 27, 2018

@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
Copy link
Contributor Author

a3f commented Jan 27, 2018

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

@Martinfx
Copy link
Contributor

Martinfx commented Feb 4, 2018

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
Copy link
Owner

raysan5 commented Feb 4, 2018

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

@a3f
Copy link
Contributor Author

a3f commented Feb 4, 2018

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

@raysan5
Copy link
Owner

raysan5 commented Feb 4, 2018

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
Copy link
Contributor

jubalh commented Feb 5, 2018

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

@Martinfx
Copy link
Contributor

Martinfx commented Feb 5, 2018

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

@jubalh
Copy link
Contributor

jubalh commented Feb 5, 2018

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
Copy link
Contributor

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

@a3f
Copy link
Contributor Author

a3f commented Feb 16, 2018

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

@Martinfx
Copy link
Contributor

Martinfx commented Feb 16, 2018

@a3f Yes is used.

@a3f
Copy link
Contributor Author

a3f commented Feb 16, 2018

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

@Martinfx
Copy link
Contributor

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

@gen2brain
Copy link
Contributor

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

@jubalh
Copy link
Contributor

jubalh commented Apr 9, 2018

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

@gen2brain
Copy link
Contributor

gen2brain commented Apr 9, 2018

@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
Copy link
Contributor

jubalh commented Apr 9, 2018

I see. I always forget about the OpenAL.

@gen2brain
Copy link
Contributor

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

@mandeep
Copy link

mandeep commented Jul 30, 2018

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

@jubalh
Copy link
Contributor

jubalh commented Jul 30, 2018

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

@raysan5
Copy link
Owner

raysan5 commented Jul 30, 2018

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

@raysan5 raysan5 closed this as completed Jul 30, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This is an improvement of some feature help needed - please! I need help with this issue
Projects
None yet
Development

No branches or pull requests

10 participants