The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Sam, Ryan?

-Shawn

On 2014-07-03 18:41, Daniel Gibson wrote:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

There's auto tools because that's the karma we *nix lovers have to bearThen there's CMake because people contributed and we were looking for a way to get rid of our karma.
And then there's premake because we did a GSOC project trying to get rid of CMake and auto tools, and also the hand crafted XCode and VS projects.


None of these is the end all be all solution...yet.


2014-07-22 0:22 GMT-03:00 Shawn Walker:




--
Gabriel.

I'm leaning towards CMake because it makes my life easier, being more and more cross-platform friendly. It can also generate all those hand-made projects by itself, meaning we could support only one build system. We already have SDL compiling with it (and successfuly), why not just go for it?

CMake doesn't depend on bash or any other Linux tool as auto tools does (not that I don't like/use them myself, I'm a linux user), which is a big win the way I see it.


I'm all in favor.



2014-07-22 10:17 GMT-03:00 Gabriel Jacobo:

Last time this was discussed the problem with CMake was that it doesn't generate VS and XCode projects with relative paths, hence creating the need to have CMake installed for those that wish to use these dev environments.

2014-07-22 19:07 GMT-03:00 Leonardo Guilherme:




--
Gabriel.

I understand.

The idea is really for the developer to have CMake installed and generate the project themselves for whatever compiler/IDE they have available and not to distribute the project generated by it.


It is not hard to install (far easier than MinGW + autotools IMO) and it can add itself to the PATH on platforms where this matters.


In my opinion the gains are much greater than the losses (and the burdens of having to install it), both for SDL developers and for its users who wants to compile the latest versions of it. For the regular user, I don't see much gains (except running CPack and generating installers), as they usually only see the built files.


Not my decision to favor CMake versus the others, but if there's another discussion between those who decide it, count me as a supporter of this idea.




2014-07-22 20:07 GMT-03:00 Gabriel Jacobo:

Isn't CMake supposed to be installed on the development machine anyways?
I've been using it quite some time now, and as far as i know you
distribute the CMakeLists.txt files, and before you build, you use CMake
(which you need to have installed obviously) to generate some platform
specific build script like "make" or XCode projects etc.

you're not supposed to share the generated project files with others

Am 23.07.2014 01:07, schrieb Gabriel Jacobo:
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If I would start from scratch nowadays I would most likely use CMake. I have always used autotools or hand made Makefiles. But this a pain to use if you need to support a lot of systems. A collegue made a cool build system based on CMake for a project called oryol (available on github). You might want to check it out. Currently supported are windows, linux, macosx, android, ios, nacl and emscripten. Am 23.07.2014 04:48 schrieb "Robotic-Brain":

The issue with CMake is its incomplete and inconsistent/inaccurate documentation, along with the fact that it may or may not actually support things like OS X bundles properly (this is some of the inconsistent and incomplete documentation…) IF it works, it works well. If it doesn't then it's very difficult to get the desired result at all.


Autoconf by contrast doesn't support them directly at all and expects you to write a Makefile yourself. If you assume you're dealing with EITHER of GNU or BSD make, you can pretty much be assured that you can produce a working Makefile that'll get the job done. Automake can also cope, though that's a little harder to do. You'll note SDL does not use automake.


The real problem is that anything that does what CMake does is going to have to, by necessity, do magic for you and force your build system to behave a certain way. To people used to *make, it's an unnatural way. Probably superior for many reasons, but unnatural. But it means they do not intuitively understand it. Add to that the lack of preprinted modules, the "official" modules that didn't actually work reliably, and the generally incomplete nature of its documentation and the average developer will try it, decide that here be dragons, and go back to autoconf with a bad taste in their mouth for CMake.

JosephSent via iOS beta, so … bugs


On Jul 22, 2014, at 22:27, M. Gerhardy wrote: