i updated and fixed up sfml-1.2.ebuild i found on the web (google cache) with the help from #gentoo-dev-help and the forums. http://forums.gentoo.org/viewtopic-p-5475974.html#5475974 sfml is a simple and fast light media library similar to sdl. http://www.sfml-dev.org/
Created attachment 181916 [details] sfml-1.4.ebuild (New Package)
ok, i found a problem. the ebuild submitted has emake install DESTDIR="${D}"/usr || die but that installs to a double /usr, so i removed the /usr emake install DESTDIR="${D}" || die that installs fine, but now have QA problems. * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libsfml-audio.so -> /var/tmp/portage/media-libs/sfml-1.4/image//usr/lib/libsfml-audio.so.1.4 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libsfml-graphics.so -> /var/tmp/portage/media-libs/sfml-1.4/image//usr/lib/libsfml-graphics.so.1.4 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libsfml-network.so -> /var/tmp/portage/media-libs/sfml-1.4/image//usr/lib/libsfml-network.so.1.4 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libsfml-system.so -> /var/tmp/portage/media-libs/sfml-1.4/image//usr/lib/libsfml-system.so.1.4 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. * QA Notice: Found an absolute symlink in a library directory: * usr/lib/libsfml-window.so -> /var/tmp/portage/media-libs/sfml-1.4/image//usr/lib/libsfml-window.so.1.4 * It should be a relative symlink if in the same directory * or a linker script if it crosses the /usr boundary. these were the errors from the ebuild i found online for version 1.2. i was trying to fix these errors by fixing the makefile with the 3 sed lines. i am not sure what needs to be done to fix this
Created attachment 182281 [details, diff] Patch for 1.4-r1 ebuild candidate
Created attachment 182282 [details] 1.4-r1 ebuild candidate
i looked at your patch and that doenst use prefix ? that needs to be added so that this can also work with gentoo-prefix and be a correct makefile.
Created attachment 182344 [details, diff] Patch for 1.4-r1 ebuild candidate I fixed the patch so it has more upstream potential. Can you elaborate on the use of prefix, maybe point me to some docs?
quoting from the patch: +ifeq (x$(DESTDIR), x) + export DESTDIR = /usr/local +endif that looks like a really bad idea. the idea of a DESTDIR is that i can install stuff to a temporary location instead of directly installing into the system and move the files where they belong afterwards (after inspecting and possibly altering the results of the installation). so e.g. it would make sense to have a PREFIX=/usr/local, and DESTDIR=/var/tmp/foo, such that files that go to bin/mybin, or /usr/local/bin/mybin given our prefix, end up in /var/tmp/foo/usr/local/bin/mybin, which is just $DESTDIR$PREFIX/bin/mybin, first. Now. if I leave DESTDIR empty, that means I want to install directly into my system. If you set DESTDIR to /usr/local, the files would end up in $DESTDIR$PREFIX, which is /usr/local/usr/local which is most definitely a place I wouldn't want them to be.
on a sidenote, this is not shell. you can just use ifeq($(FOO),) to check if FOO is empty.
you can also check if a variable is undefined, using the origin command, like this: ifeq ($(origin FOO), undefined) for more, see http://www.gnu.org/software/make/manual/make.html
Created attachment 182658 [details, diff] Adds proper support for DESTDIR and prefix How about this one?
Created attachment 182660 [details, diff] Adds proper support for DESTDIR and prefix Same *** but with dos2unix after. Now it at least works here #&]$%!
Created attachment 182665 [details, diff] Removes bundled libpng, libjpeg, GLEW and zlib
Created attachment 182667 [details] 1.4-r2 ebuild candidate libsfml seems to be a bring-everything library: they ship their own libjpeg, libpng, and a few more. They new ebuild adds another patch to use libs from the system, instead For now the remaining two exceptions are "SOIL" and "stb_vorbis" for which no ebuilds seem to exist, yet.
Created attachment 182674 [details, diff] Removes bundled libpng, libjpeg, GLEW and zlib Fixed: Part of the destdir patch made it in here as well by mistake.
i just sfml-1.4-r2, it builds and installs fine. should the headers be in a folder? /usr/include/SFML/*.hpp right now it is just /usr/include/*.hpp #and subfolders
(In reply to comment #15) > i just sfml-1.4-r2, it builds and installs fine. should the headers be in a > folder? /usr/include/SFML/*.hpp Good idea. I made it $(prefix)/include/sfml/ though, as lowercase seems to be more common in there. Please get sfml-1.4-r3 from my playground overlay: http://git.goodpoint.de/?p=overlay-sping.git;a=tree;f=media-libs/libsfml;hb=HEAD
i dont think lowercase will work. http://www.sfml-dev.org/documentation/1.4/ shows an example with #include <SFML/Graphics.hpp>, the documentation uses uppercase, i think that is what should be used.
(In reply to comment #17) > [..] the documentation uses uppercase, i think that is what should be used. libsfml-1.4-r4 is using uppercase again.
sping i just tried sfml-1.4-r4.ebuild. the patch fails, is the patch broke or did i do something stupid ? noose sfml # cat /var/tmp/portage/media-libs/sfml-1.4-r4/temp/sfml-1.4-destdir-r5.patch-32639.out ***** sfml-1.4-destdir-r5.patch ***** ===================================== PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < /usr/local/portage/overlay-local/media-libs/sfml/files/sfml-1.4-destdir-r5.patch ===================================== can't find file to patch at input line 5 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff --git a/src/SFML/Audio/Makefile b/src/SFML/Audio/Makefile |index 109a00a..f55c280 100755 |--- a/src/SFML/Audio/Makefile |+++ b/src/SFML/Audio/Makefile -------------------------- No file to patch. Skipping patch. 2 out of 2 hunks ignored can't find file to patch at input line 24 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- noose sfml # ls -l total 20 -rw-r--r-- 1 root root 1787 Mar 6 14:00 Manifest drwxr-xr-x 2 root root 184 Mar 6 14:00 files -rw-r--r-- 1 root root 891 Feb 2 17:13 sfml-1.2.ebuild -rw-r--r-- 1 root root 973 Feb 20 14:50 sfml-1.4-r2.ebuild -rw-r--r-- 1 root root 917 Mar 6 13:59 sfml-1.4-r4.ebuild -rw-r--r-- 1 root root 824 Feb 13 18:27 sfml-1.4.ebuild noose sfml # ls -l files/ total 20 -rw-r--r-- 1 root root 2744 Feb 20 15:00 sfml-1.4-deps.patch -rw-r--r-- 1 root root 4643 Feb 20 14:58 sfml-1.4-destdir-r3.patch -rw-r--r-- 1 root root 4517 Mar 6 14:00 sfml-1.4-destdir-r5.patch
doh. i didnt grab the patch correctly. the source is littered with windows line endings and the patch has those too. wget -O sfml-1.4-destdir-r5.patch 'http://git.goodpoint.de/?p=overlay-sping.git;a=blob_plain;f=media-libs/libsfml/files/libsfml-1.4-destdir-r5.patch;hb=HEAD' solved this problem.
When will this be merged? In roslin overlay the ebuild has been broken for a loong time!
(In reply to comment #21) > When will this be merged? > > In roslin overlay the ebuild has been broken for a loong time! Not to mention that version 1.6 has been out for awhile. I'll attach an updated ebuild and patches for it shortly.
Created attachment 238973 [details] Ebuild for libsfml-1.6 Ebuild for media-libs/libsfml-1.6.
Created attachment 238977 [details, diff] Fix CFLAGS and use system libs Fix CFLAGS and use system libraries.
Created attachment 238979 [details, diff] Add destdir support Add support for DESTDIR
Created attachment 258929 [details] Fix to download the correct version, x86 versus amd64 This is the libsfml-1.6.ebuild with added detection for the right bit version of the package. I have tested it briefly on my amd64 machine, and events, windows, timings and OpenGL work as far as I can see. btw: As SFML is something like a "new generation SDL", will it eventually enter portage or at least sunrise ?
Added to CVS.
The ebuild in portage does not download the right archives on 64bit systems. It downloads and tries to compile the 32bit version.
(In reply to comment #28) > The ebuild in portage does not download the right archives on 64bit systems. It > downloads and tries to compile the 32bit version. The 32bit and 64bit downloads are exactly the same except for the pre-compiled libraries that are packaged in the tarballs. Since this is Gentoo, we disregard the pre-compiled libraries and build our own so it doesn't matter which archive gets downloaded.
