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.

On Sun, Aug 24, 2014 at 12:48:28AM -0700, Bill Kendrick wrote:

So it's now 7 months later, and no one has helped build the OS X version.

It _should_ be trivial, since a lot of work was put into the codebase
right before 0.9.22 was released. In fact, a beta of 0.9.22 was made
available to users of Mac OS X 10.9-and-later, a few months earlier,
to satisfy people's need for a version of Tux Paint that works on the
newer versions of OS X.

Basically, you should be able to download the source .tar.gz
from http://www.tuxpaint.org/download/source/ and [do whatever one
does to build for OS X], and that's about it...! No code changes
should be required.

(Don't work off of CVS, since that's been changed a bit since
0.9.22 was released last August, and we're also looking into
(1) switching to SDL 2, and (2) switching to Git)

Any takers!? Thanks in advance!

-bill!
_______________________________________________
SDL mailing list

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

not sure how many times i have heard the 'it should be trivial' line but it is closely related to the attempted murders on my record

2015-03-25 19:03 GMT-03:00, Neil White:

To be fair, unless something weird is going on with the program (and
it already accounted for portability) it *should* be trivial to build
for somebody who already has the required libraries (e.g. building Sol
on Windows (and having it work) was nothing more than adding a few
#includes I had forgotten about).

It stops being trivial when programmers decide to do weird things
_______________________________________________
SDL mailing list

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

shouldt we set up an SDL master server that we can throw code at and it spits out a SDL app for all platforms?


not sure what cross compiling for mac looks like right now, probably horribly impossible,

I would describe the setup and upkeep of SDL's buildbot, and the 8
different operating systems it runs to produce 18 different build
targets, as "non-trivial."

--ryan.


_______________________________________________
SDL mailing list

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

On Wed, Mar 25, 2015 at 5:13 PM, Ryan C. Gordon wrote:


sounds like something my brother or a client would expect me to set up on a pentium II ex office dell as a server

The setup we have for SDL looks like this:

The master process runs on libsdl.org, the slave processes all run on a
machine in my office.

This office machine is massive: 12 CPU cores (x2 for hyperthreads), 96
gigabytes of RAM. There's a 400gb SSD drive dedicated to VMware
Workstation instances: WinXP/64bit, Mac OS X 10.9, Linux/x86,
Linux/amd64, Haiku, OpenBSD, FreeBSD, and Debian/kFreeBSD.

(the host machine is Ubuntu 14.04/amd64, running ZFS-on-Linux. All the
virtual machines are in a zpool that had gzip-9 compression enabled
during setup to make the most of those 400gb, and are using lzjb
compression now, so more CPU can go to the actual building effort.)

Various guests build more than one buildbot target. The Mac VM does Mac
and iOS and static analysis, the Linux/amd64 does Linux and Android and
the 32-bit one does Linux and Raspberry Pi, etc. Except places where
there is no option but cross-compiling (iOS, Emscripten, Native Client,
etc), we try to build on the real OS. Several of these could probably be
consolidated to a Linux instance--lord knows it would be faster than
Cygwin on Windows--but using the actual target seems more likely to
catch bugs.

All the guests can be ssh'd into, and VMware has a built-in VNC server
for the guests if you need a real desktop, if you aren't literally
sitting in front of the machine.

Mac OS X isn't supported on VMware Workstation, but the code it shares
with VMware Fusion for Mac guest support still exists, so we use a
hacked build of Workstation that unlocks it. Hey, I've been paying the
licensing cost on VMware every year since the 1990's. I do what I want.

--ryan.


_______________________________________________
SDL mailing list

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

(Let's not get into this discussion on the SDL mailing list, everyone.
Thanks!)

--ryan.


_______________________________________________
SDL mailing list

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