FindSDL2.cmake

Hi,

just wanted to share my FindSDL2.cmake and see whether other people
maybe have an improved it. It might also be a good idea to add this to
the repository and maintain this officially.

Regards
Martin–

http://www.caveproductions.org
http://www.ufoai.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: FindSDL2.cmake
Type: text/x-cmake
Size: 469 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20150528/c892b562/attachment.bin

+1. It would be really great to have official FindSDL2.cmake because cmake
maintainers contantly refuse to add it cmake modules. So we end up that
each project has it’s own FindSDL2.cmake version which is obviously a bad
idea.On 28 May 2015 at 15:56, Martin Gerhardy <martin.gerhardy at gmail.com> wrote:

Hi,

just wanted to share my FindSDL2.cmake and see whether other people maybe
have an improved it. It might also be a good idea to add this to the
repository and maintain this officially.

Regards
Martin

http://www.caveproductions.org
http://www.ufoai.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If an “official” cmake support is to come, the best way to do it is having
SDL configure a sdl2-config.cmake. I have provided the patches to do it in
https://bugzilla.libsdl.org/show_bug.cgi?id=2464

CMake maintainers refuse to add new CMake modules because it needs…
maintenance. If a FindSDL2.cmake is added on CMake it means CMake devs
needs to maintain them, answer to bug reports about them. Not to mention
CMake would become full of other packages Find.cmake, which is
nonsense. Have you seen the huge amount of those already?

I’m on their side, if a package can create a -Config.cmake, it should. It
already creates a sdl2-config.pc, which is autotools equivalent of
sdl2-config.cmake.

Having an official FindSDL2.cmake is nothing better than having your own:
you’d still have to bundle it with your source. Having SDL create the
sdl2-config.cmake is far easier than creating and providing a file full of
magic guessing where to find a package.Em s?b, 30 de mai de 2015 ?s 05:10, Alexey Petruchik < alexey.petruchik at gmail.com> escreveu:

+1. It would be really great to have official FindSDL2.cmake because cmake
maintainers contantly refuse to add it cmake modules. So we end up that
each project has it’s own FindSDL2.cmake version which is obviously a bad
idea.

On 28 May 2015 at 15:56, Martin Gerhardy <martin.gerhardy at gmail.com> wrote:

Hi,

just wanted to share my FindSDL2.cmake and see whether other people maybe
have an improved it. It might also be a good idea to add this to the
repository and maintain this officially.

Regards
Martin

http://www.caveproductions.org
http://www.ufoai.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The only problem is that %LIBRARY%-config.cmake is an equivalent for
package config as you said. And package config works only for Linux. So you
can’t use it for any crossplatform project anyway. So it turns out that
FindSDL2.cmake should be used anyway. And in this case instead of everyone
writing their very own FindSDL2.cmake it would much better to have and
"official" implementation.On 30 May 2015 at 16:35, Leonardo Guilherme <leonardo.guilherme at gmail.com> wrote:

If an “official” cmake support is to come, the best way to do it is having
SDL configure a sdl2-config.cmake. I have provided the patches to do it in
https://bugzilla.libsdl.org/show_bug.cgi?id=2464

CMake maintainers refuse to add new CMake modules because it needs…
maintenance. If a FindSDL2.cmake is added on CMake it means CMake devs
needs to maintain them, answer to bug reports about them. Not to mention
CMake would become full of other packages Find.cmake, which is
nonsense. Have you seen the huge amount of those already?

I’m on their side, if a package can create a -Config.cmake, it should. It
already creates a sdl2-config.pc, which is autotools equivalent of
sdl2-config.cmake.

Having an official FindSDL2.cmake is nothing better than having your own:
you’d still have to bundle it with your source. Having SDL create the
sdl2-config.cmake is far easier than creating and providing a file full of
magic guessing where to find a package.

Em s?b, 30 de mai de 2015 ?s 05:10, Alexey Petruchik < @Alexey_Petruchik> escreveu:

+1. It would be really great to have official FindSDL2.cmake because
cmake maintainers contantly refuse to add it cmake modules. So we end up
that each project has it’s own FindSDL2.cmake version which is obviously a
bad idea.

On 28 May 2015 at 15:56, Martin Gerhardy <martin.gerhardy at gmail.com> wrote:

Hi,

just wanted to share my FindSDL2.cmake and see whether other people
maybe have an improved it. It might also be a good idea to add this to the
repository and maintain this officially.

Regards
Martin

http://www.caveproductions.org
http://www.ufoai.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

That is not true, it is equivalent to package-config but works everywhere.
It works even better than any FindSDL2.cmake that you could write.

For Windows, CMake looks for directories, by default, in these places:

/
/(cmake|CMake)/
//
/
/(cmake|CMake)/

(For other paths and for other OS, check
http://www.cmake.org/cmake/help/v3.0/command/find_package.html)

If the user does not specify , its usually C:\Program Files\ (and
the x86 version) for windows, /usr for Linux. So if you have SDL installed
to C:\Program Files\SDL, its going to find the sdl-config.cmake there.
It also searches in PATH for it. And it also search inside one of these
variables:

_DIR
CMAKE_PREFIX_PATH
CMAKE_FRAMEWORK_PATH
CMAKE_APPBUNDLE_PATH

This is far more crossplatform than a list of hardcoded paths, and if
(WIN32) checks everywhere, thats what a FindSDL2.cmake usually is. The
FindSDL2.cmake that Martin sent is very simple, sensible to the variable
SDL2DIR, and to FIPS_WINDOWS which I am not even sure of what it is. CMake
itself is set to a SDL2_DIR (_DIR), so I’d say it goes toe to toe
with every other FindSDL2.cmake out there.

For the record, I’m sending my own which is based on FindSDL.cmake. Not to
mention _ttf, _img and others.

So instead of writing a FindSDL2.cmake that makes a lots of guesses on its
own, leave all that hard guessing to CMake itself, write a single
sdl2-config.cmake and be done with it.Em s?b, 30 de mai de 2015 ?s 17:21, Alexey Petruchik < alexey.petruchik at gmail.com> escreveu:

The only problem is that %LIBRARY%-config.cmake is an equivalent for
package config as you said. And package config works only for Linux. So you
can’t use it for any crossplatform project anyway. So it turns out that
FindSDL2.cmake should be used anyway. And in this case instead of everyone
writing their very own FindSDL2.cmake it would much better to have and
"official" implementation.

On 30 May 2015 at 16:35, Leonardo Guilherme <@Leonardo_Guilherme> wrote:

If an “official” cmake support is to come, the best way to do it is
having SDL configure a sdl2-config.cmake. I have provided the patches to do
it in https://bugzilla.libsdl.org/show_bug.cgi?id=2464

CMake maintainers refuse to add new CMake modules because it needs…
maintenance. If a FindSDL2.cmake is added on CMake it means CMake devs
needs to maintain them, answer to bug reports about them. Not to mention
CMake would become full of other packages Find.cmake, which is
nonsense. Have you seen the huge amount of those already?

I’m on their side, if a package can create a -Config.cmake, it should.
It already creates a sdl2-config.pc, which is autotools equivalent of
sdl2-config.cmake.

Having an official FindSDL2.cmake is nothing better than having your own:
you’d still have to bundle it with your source. Having SDL create the
sdl2-config.cmake is far easier than creating and providing a file full of
magic guessing where to find a package.

Em s?b, 30 de mai de 2015 ?s 05:10, Alexey Petruchik < alexey.petruchik at gmail.com> escreveu:

+1. It would be really great to have official FindSDL2.cmake because
cmake maintainers contantly refuse to add it cmake modules. So we end up
that each project has it’s own FindSDL2.cmake version which is obviously a
bad idea.

On 28 May 2015 at 15:56, Martin Gerhardy <martin.gerhardy at gmail.com> wrote:

Hi,

just wanted to share my FindSDL2.cmake and see whether other people
maybe have an improved it. It might also be a good idea to add this to the
repository and maintain this officially.

Regards
Martin

http://www.caveproductions.org
http://www.ufoai.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

-------------- next part --------------
A non-text attachment was scrubbed…
Name: FindSDL2.cmake
Type: text/x-cmake
Size: 6428 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20150531/7e6863d0/attachment-0001.bin

Of course your patch is the best solution - but afaik it is not on the
2.0.4 ticket list yet - maybe we should try to convince Ryan or Sam to get
it in. In my opinion this is the right way to go (as I’ve written in the
ticket for quite some time already). But even if it is applied to SDL 2.0.4
it will take some time until that is spread to the world and people still
have to deliver FindSDL2.cmake until that point.On Sun, May 31, 2015 at 3:37 AM, Leonardo Guilherme < leonardo.guilherme at gmail.com> wrote:

That is not true, it is equivalent to package-config but works everywhere.
It works even better than any FindSDL2.cmake that you could write.

For Windows, CMake looks for directories, by default, in these places:

/
/(cmake|CMake)/
//
/
/(cmake|CMake)/

(For other paths and for other OS, check
http://www.cmake.org/cmake/help/v3.0/command/find_package.html)

If the user does not specify , its usually C:\Program Files\ (and
the x86 version) for windows, /usr for Linux. So if you have SDL installed
to C:\Program Files\SDL, its going to find the sdl-config.cmake there.
It also searches in PATH for it. And it also search inside one of these
variables:

_DIR
CMAKE_PREFIX_PATH
CMAKE_FRAMEWORK_PATH
CMAKE_APPBUNDLE_PATH

This is far more crossplatform than a list of hardcoded paths, and if
(WIN32) checks everywhere, thats what a FindSDL2.cmake usually is. The
FindSDL2.cmake that Martin sent is very simple, sensible to the variable
SDL2DIR, and to FIPS_WINDOWS which I am not even sure of what it is. CMake
itself is set to a SDL2_DIR (_DIR), so I’d say it goes toe to toe
with every other FindSDL2.cmake out there.

For the record, I’m sending my own which is based on FindSDL.cmake. Not
to mention _ttf, _img and others.

So instead of writing a FindSDL2.cmake that makes a lots of guesses on its
own, leave all that hard guessing to CMake itself, write a single
sdl2-config.cmake and be done with it.

Em s?b, 30 de mai de 2015 ?s 17:21, Alexey Petruchik < alexey.petruchik at gmail.com> escreveu:

The only problem is that %LIBRARY%-config.cmake is an equivalent for
package config as you said. And package config works only for Linux. So you
can’t use it for any crossplatform project anyway. So it turns out that
FindSDL2.cmake should be used anyway. And in this case instead of everyone
writing their very own FindSDL2.cmake it would much better to have and
"official" implementation.

On 30 May 2015 at 16:35, Leonardo Guilherme <leonardo.guilherme at gmail.com wrote:

If an “official” cmake support is to come, the best way to do it is
having SDL configure a sdl2-config.cmake. I have provided the patches to do
it in https://bugzilla.libsdl.org/show_bug.cgi?id=2464

CMake maintainers refuse to add new CMake modules because it needs…
maintenance. If a FindSDL2.cmake is added on CMake it means CMake devs
needs to maintain them, answer to bug reports about them. Not to mention
CMake would become full of other packages Find.cmake, which is
nonsense. Have you seen the huge amount of those already?

I’m on their side, if a package can create a -Config.cmake, it should.
It already creates a sdl2-config.pc, which is autotools equivalent of
sdl2-config.cmake.

Having an official FindSDL2.cmake is nothing better than having your
own: you’d still have to bundle it with your source. Having SDL create the
sdl2-config.cmake is far easier than creating and providing a file full of
magic guessing where to find a package.

Em s?b, 30 de mai de 2015 ?s 05:10, Alexey Petruchik < alexey.petruchik at gmail.com> escreveu:

+1. It would be really great to have official FindSDL2.cmake because
cmake maintainers contantly refuse to add it cmake modules. So we end up
that each project has it’s own FindSDL2.cmake version which is obviously a
bad idea.

On 28 May 2015 at 15:56, Martin Gerhardy <@Martin_Gerhardy> wrote:

Hi,

just wanted to share my FindSDL2.cmake and see whether other people
maybe have an improved it. It might also be a good idea to add this to the
repository and maintain this officially.

Regards
Martin

http://www.caveproductions.org
http://www.ufoai.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


http://www.caveproductions.org