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.

Hello,

My name is Ben Henning. I'm applying for a position in Google's Summer of Code program, working to improve the build system of Simple DirectMedia Layer. My proposal is a reflection of idea #2 on the SDL GSoC ideas page:


http://www.libsdl.org/gsoc.php



I've used SDL numerous times over the years, watching the changes evolve from SDL 1.2 to SDL 1.3 and later, SDL 2.0. Nevertheless, I have a lot to learn in order to pull this off. I'm posting on this mailing list out of recommendation by future mentors of the GSoC project, but I also want to because if I need clarification or help on any aspect of SDL, I know this is one of the best places to go.


The idea for this project is to merge together and consolidate the current build systems for SDL 2.0. Currently, SDL 2.0 uses a combination of cmake, visual studio project files, and xcode project files to target various platforms. Whenever a major change happens in SDL, all of these various project files need to be updated in order to reflect the changes. Beyond that, each project file is responsible for a series of tests in order to ensure SDL is being built both correctly and optimally. This means a high level of maintenance is required to ensure the build system is correct and up-to-date, but multiply that by the number of heterogeneous build systems and we start to have a problem.


My proposal, reflecting the idea of the SDL ideas page, is to conglomerate these build systems into a single premake OR cmake setup, where premake is my primary choice but I will fallback to cmake if premake doesn't prove to be beneficial. As a stretch goal for the project, I hope to also conglomerate the build scripts for various extensions to SDL, such as SDL_mixer.


What does the SDL community think of this proposal?


Thanks,
Ben Henning

Sorry, but the application deadline was May 3rd. That's Google's
deadline, so we can't accept new proposals after that, unfortunately.

--ryan.


On 05/15/2013 04:26 PM, Ben Henning wrote:

_______________________________________________
SDL mailing list

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

Hi Ryan,

I actually already did provide a proposal. I was recommended to post my proposal to the SDL mailing list and try to receive feedback about it.


Thanks,
Ben



On Wed, May 15, 2013 at 8:41 PM, Ryan C. Gordon wrote:

One suggestion I have, would be to go through the "stdio" dumps of a current set of buildbot builds, i.e. http://buildbot.libsdl.org/waterfall

Information that could be gathered there from such "standard" builds:
- get an idea of the variety of build call sequences
- what kind of variations there are when calling the tradtional 'autotools' chain
- environment differences (and key environment variables)

Cheers,
Andreas

On 5/15/2013 10:30 PM, Ben Henning wrote:

Oh, sorry, I didn't realize that.

Fwiw, I'm really interested in seeing someone take a stab at premake4.
I'm curious to see how it stacks up against CMake, and maybe it solves
some of the problems that seem to be baked into CMake.

--ryan.



_______________________________________________
SDL mailing list

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

Ryan, what sort of problems do you mean? I'm not super familiar with CMake. I've been spending time trying to learn it in order to understand the current SDL build system.

Andreas, thanks for your suggestion. That's a really good idea. I'm going to check it out right away.


Thanks,
Ben



On Wed, May 15, 2013 at 10:30 PM, Ben Henning wrote:

Andreas,

Thanks for that reply. I'm going to look through the stdio outputs in detail. After briefly glancing at them, I noticed a lot of similarities between various build platforms. This makes a lot of sense, given most of them use GCC from what I understand.


I do have one question though. Where would I get started on understanding where the platform-dependent checks occur? I believe autoconf and automake are designed to do a lot of these checks, but I'm not sure what cmake does in this sense. I'll take a look at the cmake build files in more detail to see if this answers my question.


Thanks,
Ben



On Thu, May 16, 2013 at 6:43 AM, Andreas Schiffler wrote:

On 17.05.2013, at 22:18, Ben Henning wrote:


The key issue is that cmake itself is required on the target system for building SDL2. You cannot ship the resulting system specific build instructions (e.g. the visual studio project files), since they use absolute paths and such.

Cheers
Marcus

I have been working with premake for the last month, and I am pretty amazed. It's performance, its support for all common IDEs, as well as its extensibility, going along with a clear syntax are only few of the things that make attractive. Also, due to the fact that it is based on Lua, you can use lua scripts directly, which is very helpful for a build system.

It's only drawback is that there is no builtin support for finding external libraries, BUT it's easy to write them yourself. ( it took me just 10 minutes to write a search function for the SDL2 library, and I consider it awesome judging from my skills and experience in lua scripting at the time. )

And since premake is under the BSD license, and given that its size is roughly 500kb, it should be easy to bundle with the SDL2 source code, eliminating the need for downloading extra software to actually build SDL (*cough* cmake *cough*). At least, this is what I do for my project, and it's working well.

Finally, I'd like to say that if premake is chosen as the build system, I'd love to help writing the scripts.

Regards,
Aggelos Kolaitis

Do you know if premake can build project files that are generic enough
to run anywhere that the target IDE is installed? THAT is the killer
app that is desired for the SDL "build" system: something that can be
run on the SDL server to generate project files that are usable on an
ordinary user's machine.
_______________________________________________
SDL mailing list

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

From what I've seen that seems to be the case, though I can't confirm
since I didn't get premake to run yet :/ (also why does premake
require premake to build?!)

2013/5/18, Jared Maddox:
_______________________________________________
SDL mailing list

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

Welll, it's cause the build system of premake *is* premake (looks like the chicken-egg paradox :p)...
You could pick up a prebuilt executable from sourceforge to start off :)

On 18 May 2013 18:56, Jared Maddox wrote:





IMHO unless libraries are in the path this is an unrealistic goal for a large project like SDL which has many dependencies. The act of searching for a dependency is very much target platform and machine specific, also a step which would be performed before the generation of a project file is complete.


--Liam

The problem is that many programmers using SDL want something that
"just works", plain and simple. This idea works as long as the
programmer provides all the expected dependencies (as should be the
case anyway if you expect an optimal build). If the programmer wants
to do a custom build it's always possible for him/her to use the
script that does that job instead.

2013/5/19, liam mail:
_______________________________________________
SDL mailing list

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

I think the power of a premake solution has to be some custom discovery
code written in Lua.

For case where standard guesses for build dependencies cannot be
resolved, a script could resort to a brute-force search for dependencies
(i.e. http://snippets.luacode.org/snippets/Directory_Tree_Iterator_18)
with a simple pick UI if there are multiple resolutions (i.e. "Found
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A and C:\Program Files
(x86)\Microsoft SDKs\Windows\v7.1A - choose one!") and or a download UI
to pull in missing stuff from the web (i.e. "Download and install
doxygen to create HTML docs?").

--Andreas

On 5/19/2013 3:28 AM, Sik the hedgehog wrote:

_______________________________________________
SDL mailing list

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

I think that's a fair solution, Andreas. The user would only be prompted to choose for dependency differences when they are rebuilding the desired project file, and perhaps there could be some means of caching previous configurations so they can quickly build the target project files or makefiles without having to go through all the options again. The script could also easily notify the user of missing dependencies.

Liam, it's recognized that any sort of universal build system will require dependency traversal and collection of some kind. There's no way to truly have all the dependencies perfectly setup beforehand, unless everything is shipped with SDL (which is obviously not optimal). Premake allows for a single build system to target multiple build targets, platforms, and architectures. Cross-platform work always requires a bit of beating and bruteforcing (at some layer) to ensure compatibility across multiple platforms and architectures. A build system is no exception. Nevertheless, once it's created, the maintenance is much lower than it currently is in terms of changing the build pipeline in any way. That is an optimal outcome for this project.


Thanks for the feedback,
Ben


On Sun, May 19, 2013 at 10:13 AM, Andreas Schiffler wrote:

<snip>


I wouldn't want to push what I'm going to describe as a GSOC project,
but it would handle our needs:
1) generate build files at meta-build-time, with the output being a
bare-bones form of make
2) use the provided makefile(s) to:
2aI) build a search tool,
2aII) use the search tool to obtain paths to required components, and
2aIII) copy those build-time paths to an additional makefile,
2b) then run that produced makefile from the original makefile,
2c) then continue with the rest of the original makefile

We'd actually be looking at a fixed structure. A "native" project file
for each platform to actually run the makefile, a fixed-form search
app that incorporates at least one code file constructed by the
meta-build system, and the actual makefile & meta-build files. If we
wanted to, then the search app could even use a severely striped-down
version of SDL2.

The job of the meta-build system would, in this context, largely be
the same as the build system, just at a slightly higher level: the
meta-build system decided whether itself or the build-system have to
find certain components.

But, like I said, I wouldn't recommend this for a GSOC. If nothing
else, a lot of build-system code (search, etc.) would probably have to
be written from scratch, possibly in C. Very tedious, and possibly
much more than a summer's worth of work. I was hoping that Premake
would come with a code library that would be useful for this.
_______________________________________________
SDL mailing list

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

Thanks for accepting my application for improving SDL's meta-building system.

Andreas, I'm wondering what the best option would be for me contacting you. Should I email you directly, post to here, or use the private discussion system I think is provided by Google?


Also, what sort of additional documentation should I read before getting started on my project? A lot of the other things are self-explanatory and I did additional research per-your suggestion, but I'm looking for anything else that would help me transition into my project better.


Thanks,
Ben Henning



On Tue, May 21, 2013 at 11:25 PM, Jared Maddox wrote: