Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Ceylo

Pages: 1 ... 3 4 [5] 6 7 ... 69
General discussions / Re: Why is SFML still using CMake 2.8 ?
« on: December 23, 2017, 09:53:33 pm »
Many Linux distros only ship CMake 2.x as such we can't really raise the minimum required version and being "older" doesn't necessarily mean, being worse off.
I'm curious to know which ones still stick with CMake 2. Even Debian which (from what I know) takes time to adopt newer packages provides CMake 3.7 through apt-get as of Debian 9. 

However this doesn't mean, we potentially couldn't support newer CMake features via a conditional check. Checkout the open GitHub issues (#758, #937) and feel free to discuss potential adjustments before creating a pull request, if you're interested in contributing. :)
Indeed it could be conditional even if I prefer a simple unique version to do things :) I've had a look at these threads, they go even further: define SFML targets AND remove the need for the FindSFML.cmake file (but add the need for the config file). I don't know yet this config file approach so will study it a bit. Especially I don't have seen it used widely so I wonder if this is the way to go.

So is it "just" a matter of doing it
This. "Modern CMake" is so much better than what we have.
For a few seconds I wondered if it was sarcastic :D

General discussions / How is SFML going?
« on: December 23, 2017, 03:24:12 pm »

I've been following SFML for quite a long time (starting from the 1.4 era) where it was still developed by a few persons before going toward community development around SFML 2. Then I stopped following SFML around summer 2015.

Now I come back slowly to it and I wanted to know how it is going. I have seen a LOT (too much to read everything ;D) of discussions about future topics like SFML 3 and what should come next. But when looking at SFML Git history it looks rather calm, 3 to 10 commits per month. Like if these discussions had no conclusion. Or maybe everything is happening in forks before submission for PR. Or because SFML had fully matured, I don't really know.

So I'd like to hear the impressions from the SFML development community! How does it feel like to you? What are your ambitions for SFML's future?


General discussions / Why is SFML still using CMake 2.8 ?
« on: December 23, 2017, 03:09:31 pm »

I see that in the main CMakeLists.txt, SFML requires at least CMake 2.8.3. Which is now quite old : it is referenced as "Older Reference Documentation" when your look for its documentation, and was released 2 years ago.

The other reason I'm asking this is because CMake 3 provides a feature (and probably many others) that would be quite useful for all projects that use both CMake and SFML: interface libraries.
I have found one similar post from 2014 about it : cmake 3.0: Config-file Packages. But it's not available with FindSFML.cmake at the moment.

Basically this would mean one could write:
find_package(SFML 2 COMPONENTS network system)
target_link_library(MyExe PRIVATE sfml)
And that's all. Automatic handling of debug/release versions of SFML, not need to care about SFML_INCLUDE_DIR or SFML_DEPENDENCIES (static case would be written exactly the same).

So is it "just" a matter of doing it or there are other reasons?



In a project based on SFML I want to run tests on macOS using the provided frameworks. I don't want to install the frameworks, but instead set rpath correctly and put the frameworks next to my executable, so that I can check that I'm able to provide a fully self-contained package without depending on any installation.  Right now this means I need to copy these frameworks next to my executable:

My project is based on CMake and I want this to be automatic, so I use the provided FindSFML.cmake which provides these variables after doing a find_package(SFML):
SFML_LIBRARIES:    the list of all libraries corresponding to the required modules
SFML_FOUND:        true if all the required modules are found
SFML_INCLUDE_DIR:  the path where SFML headers are located (the directory containing the SFML/Config.hpp file)
SFML_DEPENDENCIES: the list of libraries SFML depends on, in case of static linking

However SFML_LIBRARIES only contains the direct dependencies (ie. the sfml-audio, sfml-graphics, sfml-network, sfml-system and sfml-window frameworks). So I could copy these next to my executable. But SFML_DEPENDENCIES is empty when using frameworks, most likely on purpose because it states that it's only for static linking. But then I don't know how I can get the path to the other frameworks just with a correct SFML_ROOT and find_package(SFML). Is it possible at the moment?

In the worst case I can probably hardcode the other paths but I would really like to avoid this if possible. This looks wrong and instead changes in FindSFML.cmake would probably be better.


General / Re: SFML 2.4 does not compile with g++. JPEG error. (Linux)
« on: September 14, 2016, 12:30:15 am »

I'm posting here because I'm having the same issue:
Code: [Select]
/usr/bin/ld: warning: libjpeg.so.8, needed by /usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so, not found (try using -rpath or -rpath-link)
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_std_error@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_set_defaults@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_start_compress@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_set_quality@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_stdio_dest@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_finish_compress@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_CreateCompress@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_destroy_compress@LIBJPEG_8.0'
/usr/local/SFML-2.4.0/lib/libsfml-graphics-d.so: undefined reference to `jpeg_write_scanlines@LIBJPEG_8.0'
collect2: error: ld returned 1 exit status

I know I can rebuild SFML, but as I'm distributing binaries it is annoying if users can't then just use my library + SFML downloaded from SFML website.

I checked what I have on my system (Debian 9)
Code: [Select]
$ locate libjpeg.so

And a search through the repo shows this:
Code: [Select]
apt-cache search libjpeg
gem-plugin-jpeg - Graphics Environment for Multimedia - JPEG support
imgsizer - Adds WIDTH and HEIGHT attributes to IMG tags in HTML files
jp2a - converts jpg images to ascii
libjpeg-dev - Development files for the JPEG library [dummy package]
libjpeg-turbo-progs - Programs for manipulating JPEG files
libjpeg62-turbo - libjpeg-turbo JPEG runtime library
libjpeg62-turbo-dev - Development files for the libjpeg-turbo JPEG library
libturbojpeg0 - TurboJPEG runtime library - SIMD optimized
libturbojpeg0-dev - Development files for the TurboJPEG library
Showing details of package libjpeg-dev says that it only depends on libjpeg62-turbo-dev. So obviously I won't get libjpeg8 here.

I can't say I'm satisfied with rebuilding SFML, providing my library and have some users happy because they also have libjpeg.so.62, and some others unhappy because they have libjpeg.so.8 and they need to rebuild my library.

Is there any solution at all to provide suitable binaries with my current system?
Also I don't know how related are libjpeg.so.8 and lijpeg.so.62. Is 62 just a newer (incompatible) version or is it using an unrelated versioning scheme?



I've fixed the website, thanks for your comments :)
As for MinGW it is not officially supported, although you can probably get things working if you tweak the build system a little bit. I don't officially support it anymore because with all the MinGW variants it was requiring more time than what I wanted to spend on it. So indeed I recommend using VS215.

I am pleased to announce support for textual (srt, ass/ssa, ...) subtitles in addition to the already existing support for bitmap subtitles :)
See here for more details.
Thank you feliwir for your contribution!

Thank you, going to look at it to get it integrated in the official release :)

You're not supposed to run build_ffmpeg.sh, just usual CMake + Visual Studio build, see Getting Started page.

Building from Visual Studio will use your MSYS2 installation (and its bash) when appropriate, so you would not need to bother the build_ffmpeg.sh or msys2_shell.bat. About diffutils and pkg-config, they can help FFmpeg configuration but I don't think they are required.

Note that if you only used build_ffmpeg.sh, you only have FFmpeg binaries right now, but no sfeMovie binary.

@sfUser can you check the config.log file from FFmpeg-objects directory in your build directory? At some point it should give more details on why "cl is unable to create an executable file".
You should not need to delete link.exe as building from VS puts VS utilities first in PATH. You're building from VS2013 or 2015, right? With MSYS2 installed?

@DarkRoku so fast :p I guess you built your own FFmpeg binaries for Android then told CMake to use these when configuring sfeMovie build?

@sfUser: I don't want to give prebuilt version to solve your specific case, I prefer to fix what's going wrong. What error do you get?

@DarkRoku: it is not planned. Feel free to fork the project if you want to start the port. I can provide you with support for questions you'd have about sfeMovie itself :)

General discussions / Re: Experimental internal-context-less branch
« on: October 11, 2015, 07:56:01 pm »
I guess I wasn't clear enough in my original post.
I guess I should really not post right after waking up ::)
Going to test your branch.

Edit: no trouble with sfeMovie. It only uses an OpenGL context on main thread though, so it doesn't test the annoying case.

General discussions / Re: Experimental internal-context-less branch
« on: October 09, 2015, 08:16:59 am »
Can you explain why these contexts are an issue?
A few more MB is no trouble for today's computers. So if it breaks usages (can you states which ones?) I'm not convinced it's a good idea.

FFmpeg version used by sfeMovie has been updated and full build has been successfully tested with Visual Studio 2015. There are no binaries for this version yet but at least you can build from sources for MSVC 2015.

See Getting Started page for how to build.

Hi iride,

It's not possible yet: current FFmpeg version doesn't build fine with VS2015. So provided FFmpeg version needs to be updated. Will check it but it'll take a bit of time.

Pages: 1 ... 3 4 [5] 6 7 ... 69