I think there are a number of good points being discussed, but as much as I really enjoy cmake, I also understand that MSVC/Windows development feels ridiculously different than developing for a Unix-like system.  On Windows, developers want the feeling that they can just click one or two things, and without any configuring, get a reasonable build from a library.  In Unix, I expect to have to run into hurdles, and since I can do almost everything i need in a few terminal commands, that's not a problem, but Windows is rarely setup to be easy to use like this, even when the main user is a developer.  But anyway, I don't want this to boil down to a debate of competence - all I'm saying is that Windows developers expect this sort of behaviour from a library, so there is not much sense going against the grain.<div>
<br></div><div>Here is what I recommend:</div><div><br></div><div><ul><li>Transition away from autotools in favour of cmake - I think our cmake scripts could use a little work, which could be properly done if we make an absolute decision to drop autotools.</li>
<li>SDL release/repo side, we could MSVC projects, and run a script (I'm sure we could cook up some sort of python script to do this quickly and efficiently) to look for all paths in the MSVC xml files, and convert them into relative paths where appropriate.  The end-developers don't ever need to interact with this script, and we should clearly document if there are any hitches or build variables they need to be away of, since I don't think we will ever get a 100% one-size-fits-all script. <i> There wouldn't be much point in getting those developers who have issues to download python, because then they'd be better off just dealing with cmake.</i></li>
<li>I don't know the situation with XCode, but for now, I'll make the assumption that we could do similar to the MSVC/python script fixing I previous suggested.  I suspect it would be less complex (are paths for binaries like XCode fixed in Mac?), but I don't use a Mac or XCode.</li>
<li>Linux users can generate makefiles with cmake.</li></ul><div><br></div><div>CMake would always be available in case anyone from any OS/build system wants to do some sort of custom build.</div><div><br></div><div>We should also regularly release MSVC binaries that would be available to download - this is fairly standard for most cross-platform libraries that may require extra dependencies that may not always be easy to build - I don't think there is a huge set of third-party dependencies in Windows for SDL, but this is just another thing that many Windows developers expect, and again, not because of a lack of competence - it's just the expectation.</div>
<div><br></div><div>I think this covers all the bases.  Windows developers should get a fairly well working Visual Studio projects for MSVC 2008/2010/2012, binaries, and everyone gets a fairly straight-forward way to build the library.  CMake remains an option for doing custom builds on all platforms.</div>
<br><div class="gmail_quote">On Sun, Mar 24, 2013 at 11:15 AM, Gabriel Jacobo <span dir="ltr"><<a href="mailto:gabomdq@gmail.com" target="_blank">gabomdq@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">2013/3/24 Ryan C. Gordon <span dir="ltr"><<a href="mailto:icculus@icculus.org" target="_blank">icculus@icculus.org</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Ideally we would use something make-ish that was generic enough to act<br>
as both a build system, AND a configure system, but I don't recall any<br>
logic languages being standard installs anywhere.<br>
</blockquote>
<br>
Ideally we want Windows people to find a Visual Studio project that matches their version of Visual Studio, double-click it, and build the library.<br>
<br>
Right now we're maintaining several .vcproj files for different versions, and almost universally, some subset of them fails to get updated when we change a project setting of add/remove files. Tests are missing from many of them, etc.<br>


<br>
XCode is slightly better about this, but still suffers from the fact that it's not necessarily our primary way to build SDL (even on Mac, I'm using the configure script, for example), so it isn't well-maintained either.<br>


<br>
If not CMake, something that allows us to do what CMake does is really really interesting: we maintain one text file, it spits out projects for lots of tools. But we really don't want the Windows/Mac experience to be like this:<br>


<br></blockquote><div><br></div><div><br></div></div><div>Anyone with premake [1] experience? On paper it looks like it fits the bill exactly, and it's small enough that it could be beaten into our mold should it try to resist us :)</div>

</div><br clear="all"><div><br></div><div><br></div><div>[1] <a href="http://industriousone.com/premake" target="_blank">http://industriousone.com/premake<span class="HOEnZb"><font color="#888888"><br></font></span></a><span class="HOEnZb"><font color="#888888">-- </font></span></div>
<span class="HOEnZb"><font color="#888888">Gabriel.
</font></span></div></div>
<br>_______________________________________________<br>
SDL mailing list<br>
<a href="mailto:SDL@lists.libsdl.org">SDL@lists.libsdl.org</a><br>
<a href="http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org" target="_blank">http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org</a><br>
<br></blockquote></div><br></div>