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 - Jonny

Pages: [1] 2 3 ... 8
General discussions / Re: External libraries' versions
« on: April 26, 2019, 12:11:38 am »
The versions of the pre-built libraries varies by platform (All the more reason to get them build as part of the source tree: https://en.sfml-dev.org/forums/index.php?topic=25053.0)

This repository contains the revisions of each of the dependencies which is known to work with SFML on all platforms: https://github.com/eXpl0it3r/SFML-dependencies

General discussions / Re: Android x64 support
« on: April 26, 2019, 12:09:17 am »
Should be easily solvable once there's a decision on how to build deps from source: https://en.sfml-dev.org/forums/index.php?topic=25053.0

General / Re: CMake android build errors
« on: March 22, 2019, 07:18:59 pm »
I beleive you're looking for x86_64 (_ instead of -)

SFML development / Re: Removing dependency binaries
« on: March 14, 2019, 06:35:13 pm »
Personally I don't think it's a good idea to add another requirement/dependency like that just to manage our dependencies

SFML development / Re: Removing dependency binaries
« on: March 11, 2019, 03:14:27 pm »
Subtree looks like a reasonable compromise, although information on it is a little thin spread.

We also have to consider that using git-submodule is a breaking change for everyone that has a more or less automated workflow (bash/batch scripts that update and build SFML).

It doesn't have to be - the submodules can be cloned/updated as part of the cmake script

Ultimately I don't mind too much, I'm just keen to see a decision made, if you have a better suggestion than a poll to get this done that's absolutely fine by me.

Window / Full screen problems on macOS Mojave
« on: March 10, 2019, 04:15:09 pm »
I'm getting a very strange issue with full screen: When turn full screen on then off again, the window is duplicated so I have two instances of the same window (but one doesn't have any render context, just a blank window).

I'm on macOS mojave building with Xcode 10. I'm aware there are some other issues in the latest SDK with openGL so I'm wondering if anyone else can confirm this issue?

Window / Re: iOS Sample Code
« on: March 10, 2019, 04:12:36 pm »
The latest version of the pong SFML example implements touch input

SFML development / Re: Removing dependency binaries
« on: March 08, 2019, 11:46:12 pm »
Git submodules were a pain every single time I had to do more with them than just git clone --recurse-submodules.

You wouldn't have to do anything more with them than just git clone --recurse-submodules

Less user-friendly for every SFML user due to extra setup step (you can expect 100s of forum posts "why does my code not compile")

It can be made extremely simple. We can use cmake show a warning if the user hasn't cloned the submodules, telling them exactly which command to run. We can also use cmake to actually check out the submodules if the user hasn't already

We introduce a third-party dependency. If that third-party repository goes down, SFML will not be possible to build, with no backup (rolling back to previous version past now won't work)

Given all the repositories except one are hosted on github, the likelihood of this being an issue is almost nil. If it's a concern we can also easily mirror them in repos we have control over

It's not even clear if all the dependencies we currently use have official and stable Git repos. If not, we would need to provide a mirror (i.e. extra maintenance).

They all have official git repositories, and even IF we were to mirror them (which I don't think we need to do) the maintenance would be equal to maintaining the source in the SFML repo (i.e. almost nil)

subtree looks interesting. Haven't tried it myself but worth considering. I'd be interested to see and try a working example of it

And I would appreciate if the decision were made based on technical arguments, not polls from a handful of people that happen to be around at the time the matter is discussed

I think we've pretty much already covered all the technical arguments, there's not really too many facets to discuss. At this point it comes down to personal preference, so a poll seems reasonable.

In the interest of fairness, here are the submodule advantages that were already mentioned:

  • Better visibility over dependency versions
  • Easier testing of newer dependency versions (just git checkout/pull the revision you want to test)
  • Easier access to dependency history for bisecting/debugging/testing
  • Less risk of human error when updating or changing dependencies
  • Easier to contribute changes upstream

As I said before I don't think there's a clear technical reason to choose one or the the other (They are almost identical in practice) so we just need a decision made. It's super easy to change and the implementation is pretty much done. We just need a decision so this doesn't turn into another dead discussion

SFML development / Re: Removing dependency binaries
« on: February 25, 2019, 05:48:16 pm »
RE SFML_USE_SYSTEM_DEPS - I agree, this is also what I suggested earlier.

I still would prefer to use git submodules over just copy/pasting the code into the repo. I will concede it adds a tiny bit of complexity for the end user, but I think it makes it easier for contributors, particularly for maintenance and testing features/bugs in different versions of dependencies. Other than having to add an extra parameter to your first clone of the repo, all the downsides of submodules are also present when just including the raw source

I don't feel particularly strongly about it though, so I'd rather just decide on a direction so we can start implementing something

For reference, freetype2 takes <8 seconds to build on my laptop, I doubt there's much deviance from that

Update: Having gone back to the work I've done previously on this, one of the larger issues is handling the target exports as we need all the dependency targets to be part of the export target, assuming we use add_subdirectory. This might require a small amount of patching for each dependency

Another update: Proof of concept using submodules here if anyone wants to check it out https://github.com/JonnyPtn/SFML/tree/build_deps .Having a slight issue on macOS where there's an openAL thread chewing up all the CPU (any ideas on that?). Otherwise, it's working pretty well

SFML development / Re: Removing dependency binaries
« on: January 30, 2019, 02:00:38 pm »
Relying on the user to provide the binaries assumes the correct version will be available. I'd prefer for this to be an option rather than the default (Applies to all platforms, as vcpkg can easily provide all dependencies on windows too). We also already have a "USE_SYSTEM_DEPS" flag for exactly that reason

Also updating submodules shouldn't be tedious at all - it's just a small handful of git commands and shouldn't take more than a few minutes

I think submodules + CMake's ExternalProject would be really nice to use

ExternalProject can be given a git repo and commit to checkout, so there would be no reason to use the submodules. I see these options:

- Use git submodules and just add_subdirectory() in cmake.
- Use ExternalProject which does a git checkout and build when sfml is build
- Use FetchContent and add_subdirectory

Personally I like option 3 best, but I think FetchContent is only available in cmake 3.11 so that would require a version bump.

Options 1 and 3 allow the dependencies to be configured at the same time as SFML is configured, whereas option 2 would configure the dependency at build time so you'd need to hardcode some values in the cmake configuration

SFML development / Re: Removing dependency binaries
« on: January 26, 2019, 08:22:03 pm »
I'll help as much as I can.

Personally I think it would be a good idea to either use git submodules or cmake to maintain the dependency source code (I'd prefer the latter). They would both allow easier dependency updates, make it easier to identify which version of the dependency is being built, and make it easier for contributors to build against different dependency versions if needed

The only down side would be if the user clones the repo (and forgets to clone with submodules) then goes offline they will not be able to build SFML, but I think this is a rather specific and rare case

General / Re: OSX Sierra static runtime broken
« on: August 27, 2018, 12:50:51 pm »
Milerius, Give this Pull request a try if you can. It should solve the issue: https://github.com/SFML/SFML/pull/1485

Window / Re: glCheck() not available in window module
« on: August 16, 2018, 08:10:38 am »
So is there any reason that it couldn't/shouldn't be in the Windows module? What's the "rule" that EAGLContext is an exception to? Just that openGL isn't "normally needed"? Is the argument just that it makes more sense to be in the graphics module? Would you accept if it was duplicated in the windows module? or just defined in EAGLContext.mm?

Regardless of that specific issue (I only mentioned it for context), would it not be an advantage to have gl error checking wherever possible?

General / Re: Travis build file?
« on: August 16, 2018, 07:52:33 am »
I do it slightly differently and just use the default install paths. This set up builds with multiple compilers and for macOS (it's a little messy I admit...) https://github.com/JonnyPtn/SFML-DOOM/blob/master/.travis.yml

Window / glCheck() not available in window module
« on: August 15, 2018, 04:49:50 pm »
While trying to debug https://github.com/SFML/SFML/issues/1471 I noticed that none of the gl functions in the windows module are wrapped by glCheck(). As it's defined in the graphics module this makes sense, because the window module doesn't (and shouldn't) depend on the graphics module. But I was wondering if there was a reason this couldn't be moved into the window module, so that we can error check all the gl functions there as well?

Pages: [1] 2 3 ... 8