Google Summer of Code applicant

SDL Development
1

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

2

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:

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

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

3

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,
BenOn Wed, May 15, 2013 at 8:41 PM, Ryan C. Gordon wrote:

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:

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

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

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

4

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,
AndreasOn 5/15/2013 10:30 PM, Ben Henning wrote:

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 <icculus at icculus.org <mailto:icculus at icculus.org>> wrote:

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:

    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


    _______________________________________________
    SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto: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

5

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.

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.

6

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,
BenOn Wed, May 15, 2013 at 10:30 PM, Ben Henning <@Ben_Henning>wrote:

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:

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:

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

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

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

7

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,
BenOn Thu, May 16, 2013 at 6:43 AM, Andreas Schiffler 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:

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:

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:

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

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 listSDL at lists.libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

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.

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
MarcusOn 17.05.2013, at 22:18, Ben Henning <henning.benmax at gmail.com> wrote:

9

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

Ben Henning wrote:> 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 (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

C is the God’s Programming Language

10

Message-ID: <1368883293.m2f.37125 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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.> Date: Sat, 18 May 2013 06:21:34 -0700

From: “neoaggelos”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant

11

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 :confused: (also why does premake
require premake to build?!)

2013/5/18, Jared Maddox :>> Date: Sat, 18 May 2013 06:21:34 -0700

From: “neoaggelos”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant
Message-ID: <1368883293.m2f.37125 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

12

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 :slight_smile:

Sik wrote:> 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 :confused: (also why does premake
require premake to build?!)

2013/5/18, Jared Maddox :

Date: Sat, 18 May 2013 06:21:34 -0700
From: “neoaggelos” <@Aggelos_Kolaitis>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant
Message-ID: <1368883293.m2f.37125 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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

C is the God’s Programming Language

13

Message-ID: <1368883293.m2f.37125 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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.

–LiamOn 18 May 2013 18:56, Jared Maddox wrote:

Date: Sat, 18 May 2013 06:21:34 -0700
From: “neoaggelos”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant

14

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 <liam.list at googlemail.com>:> On 18 May 2013 18:56, Jared Maddox wrote:

Date: Sat, 18 May 2013 06:21:34 -0700
From: “neoaggelos”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant
Message-ID: <1368883293.m2f.37125 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

15

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?”).

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

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 <liam.list at googlemail.com>:

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

Date: Sat, 18 May 2013 06:21:34 -0700
From: “neoaggelos”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant
Message-ID: <1368883293.m2f.37125 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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

16

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,
BenOn Sun, May 19, 2013 at 10:13 AM, Andreas Schiffler <aschiffler at ferzkopp.net wrote:

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_18http://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:

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 <liam.list at googlemail.com>:

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

Date: Sat, 18 May 2013 06:21:34 -0700

From: “neoaggelos”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Google Summer of Code applicant
Message-ID: <1368883293.m2f.37125 at forums.**libsdl.org<1368883293.m2f.37125 at forums.libsdl.org>

Content-Type: text/plain; charset=“iso-8859-1”

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.

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
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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

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

17

Message-ID:
<CAEyBR+Vtg+xCUqLeV22rvEWcFF=fJMLX2SfvH55cOdRBa5eN2Q at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

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 <liam.list at googlemail.com>:

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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.> Date: Sun, 19 May 2013 07:28:32 -0300

From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Google Summer of Code applicant

On 18 May 2013 18:56, Jared Maddox <@Jared_Maddox> wrote:

18

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 HenningOn Tue, May 21, 2013 at 11:25 PM, Jared Maddox wrote:

Date: Sun, 19 May 2013 07:28:32 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Google Summer of Code applicant
Message-ID:
<CAEyBR+Vtg+xCUqLeV22rvEWcFF=
fJMLX2SfvH55cOdRBa5eN2Q at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

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 <liam.list at googlemail.com>:

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

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

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
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org