Development Setup Under Linux


p0is0n

Still Fresh
Joined
Aug 29, 2007
Messages
24
Age
38
Location
UK
Website
Visit site
Hey all,

I am completely lost when trying to compile for the gp2x on linux.

I made a few games for the GP2X a couple years ago using DevkitPro on Windows.
However that was like 3 formats ago and I primarily use linux now.

What I need is a downloadable SDL toolchain and a makefile to make the gpe

I have tried downloading the open2x toolchain, and using http://www.wiki.gp2x.org/wiki/Dual_Makefile as a basis for my makefile, but as the open2x toolchain comes without SDL I'm a bit lost as to what to do.

If anyone can help me with (simple) instructions on how to get my .gpe's compiling under linux I would be very grateful.

Thanks!

EDIT :
I think I have the toolchain setup correctly
I used the links from here

I am still having problems with the makefile though.
 
Last edited by a moderator:
p0is0n said:
Hey all,

I am completely lost when trying to compile for the gp2x on linux.

I made a few games for the GP2X a couple years ago using DevkitPro on Windows.
However that was like 3 formats ago and I primarily use linux now.

What I need is a downloadable SDL toolchain and a makefile to make the gpe

I have tried downloading the open2x toolchain, and using http://www.wiki.gp2x.org/wiki/Dual_Makefile as a basis for my makefile, but as the open2x toolchain comes without SDL I'm a bit lost as to what to do.

If anyone can help me with (simple) instructions on how to get my .gpe's compiling under linux I would be very grateful.

Thanks!

EDIT :
I think I have the toolchain setup correctly
I used the links from here

I am still having problems with the makefile though.

2nd Edit :
I think I may have it right.
This is my makefile (purely for GP2X builds, I will make it build both when I have confirmed it works)
Code:
TARGET = ttt.gpe

VERSION = 0.1

DEL_FILE = rm -f

CROSS_PATH = /opt/open2x/gcc-4.1.1-glibc-2.3.6

CC      = $(CROSS_PATH)/bin/arm-open2x-linux-g++
CFLAGS = -pipe -Wall -g
LDFLAGS = -DGP2X `$(CROSS_PATH)/bin/sdl-config --cflags` `$(CROSS_PATH)/bin/sdl-config --static-libs`

SDL_CFLAGS = -I$(CROSS_PATH)/include/
SDL_LIBS = -I$(CROSS_PATH)/libs/SDL

SDL_TTF_LIBS	= -lSDL_ttf
SDL_IMAGE_LIBS	= -lSDL_image
SDL_MIXER_LIBS  = -lSDL_mixer

OBJECTS =	src/main.o \
			src/gfx.o \
			src/sprite.o \
			src/world.o

SOURCES =	src/main.cpp \
			src/gfx.cpp \
			src/sprite.cpp \
			src/world.cpp

HEADERS =	src/gfx.h \
			src/sprite.h \
			src/world.h


$(TARGET): $(OBJECTS)
	$(CC) $(LDFLAGS) $(SDL_LIBS) $(SDL_TTF_LIBS) $(SDL_IMAGE_LIBS) $(SDL_MIXER_LIBS) $(OBJECTS) -o $@

.cpp.o:
	$(CC) $(CFLAGS) $(SDL_CFLAGS) -c $< -o $@

clean:
	rm $(OBJECTS) $(TARGET)

NOTE : At the moment my memory card reader dosen't seem to be working so I cannot test the build out (dammned if I know what I did with the cable :eek:).
I will try and test it out by tomorrow night
 
Last edited by a moderator:
Well I finally got a chance to come back to this.
Everything seems to be working so far.
I'm very new to makefiles so this may not be the best example but here is my completed makefile for linux and GP2X builds by using "make all".
Code:
TARGET = test
TARGET_GP2X = test.gpe

VERSION = 0.1

DEL_FILE = rm -f

CROSS_PATH = /opt/open2x/gcc-4.1.1-glibc-2.3.6

ifdef gp2x
CC = $(CROSS_PATH)/bin/arm-open2x-linux-g++
SDL_CFLAGS = -I$(CROSS_PATH)/include/
SDL_LIBS = -I$(CROSS_PATH)/libs/SDL
LDFLAGS = -DGP2X $(shell $(CROSS_PATH)/bin/sdl-config --cflags) $(shell $(CROSS_PATH)/bin/sdl-config --static-libs)
else
CC = g++
SDL_CFLAGS = $(shell sdl-config --cflags)
SDL_LIBS = $(shell sdl-config --libs)
LDFLAGS = -lSDL
endif

CFLAGS = -pipe -Wall -g

SDL_TTF_LIBS	= -lSDL_ttf
SDL_IMAGE_LIBS	= -lSDL_image
SDL_MIXER_LIBS  = -lSDL_mixer

OBJECTS =	src/main.o \
			src/world.o

SOURCES =	src/main.cpp \
			src/world.cpp

HEADERS =	src/world.h

all:
		make cleanobjs
		make pc
		make cleanobjs
		make gp2x gp2x=1

pc: $(TARGET)
gp2x: $(TARGET_GP2X)

$(TARGET): $(OBJECTS)
	$(CC) $(LDFLAGS) $(SDL_LIBS) $(SDL_TTF_LIBS) $(SDL_IMAGE_LIBS) $(SDL_MIXER_LIBS) $(OBJECTS) -o $@

$(TARGET_GP2X): $(OBJECTS)
	$(CC) $(LDFLAGS) $(SDL_LIBS) $(SDL_TTF_LIBS) $(SDL_IMAGE_LIBS) $(SDL_MIXER_LIBS) $(OBJECTS) -o $@

.cpp.o:
	$(CC) $(CFLAGS) $(SDL_CFLAGS) -c $< -o $@

cleanobjs:
	rm $(OBJECTS)

clean:
	rm $(OBJECTS) $(TARGET) $(GP2X_TARGET)
 
I hate Makefiles. The day they die and are replaced with something that's actually readable, I will rejoice. Unfortunately, even things like CMake and autoconf are even bigger nightmares.

After over a year of doing things manually using notepad/nano across Cygwin and Linux, I've taken to letting Eclipse generate the Makefile for everyday coding, and I have a "GP2X" configuration for my GP2X projects - it's a pain to set up at first but only building statically-linked GPE's when you actually need them, and not having to bother about maintaining a Makefile, is much easier and quicker for me. Drop down box, select the GP2X build configuration, hey presto a static-GPE that works on my GP2X. Drop down box, select the normal configuration, hey presto a debug-symbolled, unoptimised, executable that links to the system libraries. Hell, at one point I was using a bash script that manually compiled and linked whatever I needed, the Makefile was such a nightmare.

The one thing that puts me (and the people I've taught programming) off C and GCC is the horrendous games you have to play to get it to read a couple of header/library files and compile them into a big executable. Everything from having to have "groups" of libraries specified in the correct link order on the command-line, to having to fiddle or copy files around to satisfy include directives, to them being totally non-portable if someone has a slightly different folder layout. And don't get me started on dependencies and source/header files that are multiple-included with different parameters and/or can't be #included directly because of the preprocessor magic they do, only via other files.

Save yourself some time - get a working Makefile and then keep it only for actual GP2X release versions, if that. Do everything that needs to be done every day using simpler methods - like Eclipse's automatic make process, or a script that just compiles *EVERYTHING* in the current folder into one executable for testing. I hate spending 50% of my programming time fighting with the administration of the damn thing - compilers, linkers, paths, file management, source control, etc. Eclipse saves me a lot of time on that sort of crap. I threw a MD5/SHA library and an A-star library into a subfolder of one of my projects, pressed "Run" and Eclipse just found the source, compiled it all, linked it into my executable and then all I had to do was include a header/function call in one of my files to actually use the damn thing. I right-click and exclude that folder and suddenly it disappears from the build process but stays around in case I need it.

Oh, and a "GP2X" build configuration that uses Open2x was a bit of a fiddle to set up (absolute / Cygwin paths, would have been a lot easier on Linux, though) but I didn't have to do anything special - just tick the "static" box, add in the paths to my compiler / libraries, add a few symbols to make the Open2x compiler compile to GP2X (TARGET_GP2X), and that was it. No Makefiles, no need to hand-edit anything.

I'm not normally a fan of GUI over CLI but, when programming, I want my "CLI" to be the C code, not the damn build process. And you can't beat a bit of instruction-by-instruction debugging with breakpoints and live source-view.
 
ledow said:
I hate Makefiles. rant rant rant, etc.
TBH this is my sentiments exactly... I remember originally trying to get something to build for GP2X was the larger obstacle and I spent less time coding... nowadays I'm a little more experienced with toolchains and such but still, I agree with your point.
 
Last edited by a moderator:
ledow said:
I hate Makefiles. rant rant rant, etc.
Makefiles are fine, people just tend to make them needlessly complex. Here is one I use for my latest top-secret project:

Code:
CC = path/to/gcc
CFLAGS = -Wall -O2
LDFLAGS = -lz

OBJS = main.o host_fb.o

top_secret_project: $(OBJS)
        $(CC) -o $@ $^ $(LDFLAGS)
This builds a binary called top_secret_project.
 
Last edited by a moderator:
Warning: another rant approaching, but Makefiles *really* piss me off... this isn't an attack on anyone, I just hate the things.

notaz said:
Makefiles are fine, people just tend to make them needlessly complex. Here is one I use for my latest top-secret project:

Simple Makefiles are fine for simple things. There's no static compilation in your example, or inclusion of libraries (apart from z which is pretty impact-less and has no dependencies), or path management, or proper code dependencies. Yes, it'll work if your include paths are already all correct, but otherwise it'll do nothing - now maintain two versions of the program compiled with two sets of options, two different include paths, etc. And most of the time I end up cross-compiling or using different compilers, libraries and includes - even *I'm* not always completely sure where my compiler / includes / library objects are for a particular project sometimes so that means either hard-coding them or trying to auto-detect them. If you have to specify CC etc. in environment variables, then you could have done that in a bash script. An equivalent bash script to your Makefile would be shorter and easier to understand what happens in what order. Most of what's contained in any sizeable Makefile is valid bash-isms anyway. Hell "make clean" is hardly ever anything but "rm *.o".

That's not including things like: "make: *** No rule to make target `main.o', needed by `top_secret_project'. Stop." which is what you'll get from running that example as it is. So you'd have to create another line for every file, or just put in some generic line that compiles any .c file to a .o - Kinda spoils of the point of having a Makefile when it just compiles every C file into an object and then links the object - that's a *three* line bash script. It's fine if you want to hand-compile main.c into main.o each time, but a pain in the backside otherwise.

Then you have that "8 spaces isn't a tab" crap, which is just annoying when you copy and paste such examples, and has no practical reason other than to piss off people who don't care about the difference between a tab and a number of spaces.

Any decent-size project uses autoconf, not Makefiles directly, which creates some of the most unreadable Makefiles known to man. Recent example - Cygwin discontinued use of their "-mno_cygwin" flag. It doesn't affect anything, you just have to use MinGW directly if you want a non-Cygwin executable, or just remove the -mno_cygwin flag from a project that has it and live with compiling a program that will have Cygwin dependency. For a basic Cygwin development environment that's never going to leave my computer, I don't really care about a library on my personal computer having a Cygwin dependency because it'll get replaced with non-cygwin, non-x86 libraries once I target the real device I'm programming for. The configure script won't know how to accept such a statement unless the person who wrote it was *really* forward-thinking, so it took me 30 minutes once to purge a library's Makefiles of no_cygwin statements because they were scattered all over the place. Simple job, made more difficult by the obscurity of Makefiles. I couldn't even do a simple sed on the files because of the way the Makefile was organised.

The only "advantage" of Makefiles is that they follow your prescribed dependency chain all the way through the project. That makes some things easier, but very few projects actually require such an optimal and minimal compilation scheme nowadays. Nobody really worries about accidentally including a particular object file twice, because the linker is smart enough to strip it all out for you - has been since they were first invented - it just adds a tiny little piece of time / I/O to the compilation. But miss out a single definition when compiling each c file manually via a Makefile and the compiler just freaks. It's basically all hand-managed anyway because you have to specify those prerequisites. Almost everything can just be lumped into the compiler/linker at once, and it'll sort out the duplicates / missing stuff for you. And I hate having a Makefile in every subdirectory because it's then a nightmare to track the things - most tools that do that will automate it for you anyway, but it's totally unnecessary.

Makefiles aren't easily human-readable. They also don't need to be 99% of the time. Thus it doesn't matter *what* they are, and they could easily be anything other than a Makefile that would also be easily read by a programmer who's *NOT* familiar with yet-another-syntax.

I find it telling that Eclipse's default is to let it handle the make process rather than use your Makefile. Eclipse is a huge project used for absolutely everything and yet the default is to just ignore all Makefiles and build its own. I also find it telling that Eclipse does this by basically throwing every C file that you haven't specifically excluded into an object using a simple, generic "c -> o" statement, then mass-including a list of them into a main Makefile that does nothing more than link them all together. This is what I did and still do, because it's easier to let the linker sort everything out than it is to fine-tune dependencies. And the only real advantage of a Makefile *was* its dependency resolution, so it's basically just a bash script now, but which requires another program to operate and a horrible syntax to boot. I suppose conditional compilation might be a case for some places but then I've seen some horrible hacks like having to build a program as the first half-dozen lines of the Makefile which then generates the dependencies for the remainder of it. I've seen a few large, famous projects using that kind of setup.

Also, Makefiles age and aren't particularly portable. What's valid in a Makefile today will be junk in the future, not because it's invalid syntax, but because the Makefile just isn't designed to be easily modified at all and so the code gets out of date quickly. If you don't make everything configurable, things will fall over when libraries change etc. If everything is configurable, there's nothing you couldn't have done with a bash script in that case. And if you want to hand a Makefile to another person, you better hope it's autoconf / CMake because editing a Makefile to change paths is an absolute nightmare and one better off done with an automated detection tool. Distributing Makefiles is a pain because they are inherently locked to a single config or have to be regenerated for *every* change in config. I might as well just distribute a batch file with "CC=" "INCLUDEDIR=" etc. in it - at least people stand half a chance of being able to edit it to their filesystem preferences.

The main generated Eclipse Makefile for a huge project of mine is maybe 20-30 lines of code that is mostly comments, environment variables and echo's, and the subdirectories just have a "sources.mk" that lists each c file with a generic compilation at the bottom for all of them. It's the cleanest Makefile I've ever used on a big project, I've never had to touch it, and it always works perfectly but yet to update even such a simple thing manually would be a nightmare - every time you add a c file, you add another line(s) or (more likely) forget and then have to edit the Makefile halfway through the build process. To be honest, I don't really care what it contains because I've never had to edit it. Eclipse could quite easily have been doing the dependency resolution and compilation using a DOS batch file for all I care, it just works. I would never distribute them, either, because although they'd work it would *still* be locked to my config. Thus Makefiles aren't giving Eclipse any advantage either.

Makefile's are badly realised bash scripts that people have got into the habit of using because they like to be able to just type "make" as a standard command. If you're using autoconf, then what/how autoconf does the job with is entirely out of the programmer's hands anyway - so you're not using Makefiles, you're using autoconf which could be churning out perl scripts to actually compile the code as far as you or your users are concerned (and, yes, I've seen things do just that). If you're hand-editing then any Makefile over about 10-20 lines soon becomes a pain in the arse, and you'd be better off with a virtually identical file, with a more usual syntax, and just compile the damn things via a bash script.

I used the GP2X Makefile that was on the wiki when I first started on here over a year ago. I'd programmed in C in the past but I'd always done manual compilation / linking because it was only for small projects and I was brought up that way - Makefiles weren't used when I was being taught C, or FORTRAN, or Java, or any of the other stuff I was taught. We were taught to manually compile things in order to understand what the compiler/linker were actually doing and it was never a big chore to just create a script to automate that process a little. Even with the GUI development environments available in uni, everyone was taught to hand-compile things. It was too easy for something to work in a GUI and then not work when you gave it to someone else because you'd missed something the GUI was using.

When I first "restarted" C programming, I had a bash script for compiling for PC and one for compiling for GP2X. The project I was basing on had a Makefile. Several of them. If and when they worked, I needed to edit them. When it came to stripping out PC dependencies and adding in SDL, it was easier to just write my own scripts and ignore the Makefiles entirely. Eventually I did write a Makefile, a simple one, that did the job. I did one *massive* overhaul on the Makefile to get it working how I liked and combine both GP2X and PC versions into one file. I tested it, it worked, but it still gave me more problems than the two bash scripts would have if I'd combined them. I started using Eclipse, more out of interest than anything else, and I haven't touched that Makefile since. I doubt it does anything at all any more. After that, at least two people picked up my code and compiled it for different architectures - each time they just wiped out the Makefile and started again from what I can see - I know that's what I did when I tried to compile some ancient software a while back - it was just quicker to glance at the Makefile for anything weird, wipe it out and then keep compiling/linking until there were no errors. I started taking the Makefiles off my source repositories because they were out of date and keeping them up-to-date was just an administrative chore that I didn't want.

But just point Eclipse at the folder and hey presto, it "just" compiles and "just" works. And I don't have to worry about maintaining a Visual C++ Makefile, or a MinGW one, or a Cygwin one, or a GP2X one, or some combined monstrosity. Yeah, you can't just download and type "make" but the chances of that actually just working on someone else's machine were slim without autoconf anyway.

Makefiles are just an historical artefact of Unix programming - at one point they had a purpose, now they are just a single, badly chosen tool with which the user never interacts directly beyond typing "configure; make; make install" and thus they could be *anything* - the tool that generates them is more important and has more control than the files themselves. They aren't particularly suited to the job, they aren't easy to read or easy to understand, or easy to write. They aren't portable (but the programs that generate them are), they break easily, and they *must* be kept up-to-date. Hence an automated tool is the only way to manage them, and if your automated tool did things using "makefiles" written in BASIC, or Perl, or DOS batch files, or C programs themselves, you wouldn't even notice or care so long as it compiled. Hell, even the Linux kernel people have been trying to replace the whole complicated build process with a Perl program for several years - the only objection to that seems to be that the replacement is written in Perl which adds a different dependency to normal. If the "Makefile" was some simple one-file program written in C that the scripts compiled first and then let it get on with the job of configuring everything else, nobody would even have cared or objected.

"make" itself is historic, and unnecessarily complicated. Entire projects exist to make using it a little simpler, and most of those do so by adding tons of complexity. It's not worth the effort on a modern machine. Makefiles cost me orders-of-magnitude more time than they save me, no matter what I seem to be doing.
 
Last edited by a moderator:
Warning: I don't have time to read the whole above wall of text, just a few quick comments:

ledow said:
path management
Does not have to be handled in Makefile. If you build your cross-compile gcc properly, you specify sysroot for it where it searches for libs and headers and not craming paths into Makefile. You can then switch targets like PC/ARM just by changing first line in my example.

ledow said:
proper code dependencies.
A few rules to automatically generate dependencies with GCC and include them can be added if needed. For types of projects I deal here it's typically not even needed, "make clean; make" can do all in seconds on today's machines.

ledow said:
That's not including things like: "make: *** No rule to make target `main.o', needed by `top_secret_project'. Stop."
Make has default rules. If you had main.c or main.cpp or whatever in working dir or where vpath points it would build fine.

ledow said:
So you'd have to create another line for every file, or just put in some generic line that compiles any .c file to a .o
You don't - make use of default rules.

ledow said:
Any decent-size project uses autoconf, not Makefiles directly, which creates some of the most unreadable Makefiles known to man.
I agree with that, but autohell is entirely different project.


Well in short - don't like makefiles - don't use them. For me they don't cause too many issues and I'll keep happily using them.
 
Last edited by a moderator:
ledow said:
So you'd have to create another line for every file, or just put in some generic line that compiles any .c file to a .o - Kinda spoils of the point of having a Makefile when it just compiles every C file into an object and then links the object - that's a *three* line bash script. It's fine if you want to hand-compile main.c into main.o each time, but a pain in the backside otherwise.

Seems like you're missing the point of makefiles here, which is that they only apply the rules for files which have actually changed. Usually useful so you don't have to recompile all the modules in your program every time you hit make. I think your shell script for doing this would be much more complex.

ledow said:
Then you have that "8 spaces isn't a tab" crap, which is just annoying when you copy and paste such examples, and has no practical reason other than to piss off people who don't care about the difference between a tab and a number of spaces.

Yeah, the tabs thing is horrible historical cruft that I desperately wish would go away somehow, unfortunately it doesn't seem like that many other people are that opposed to it. Maybe I'm in the minority camp that hates using tabs ever.

ledow said:
Any decent-size project uses autoconf, not Makefiles directly, which creates some of the most unreadable Makefiles known to man.

Define decent size. To me the appropriateness of autoconf has more to do with your intended portability (out of the box) and dependencies than size. It's easy to imagine a project that's dozens of thousands of lines of code but still is intended for one or a few fixed platforms and doesn't bring in a lot of dependencies. Not sure if that fits your size criteria for "decent size" yet though.

ledow said:
Recent example - Cygwin discontinued use of their "-mno_cygwin" flag. It doesn't affect anything, you just have to use MinGW directly if you want a non-Cygwin executable, or just remove the -mno_cygwin flag from a project that has it and live with compiling a program that will have Cygwin dependency. For a basic Cygwin development environment that's never going to leave my computer, I don't really care about a library on my personal computer having a Cygwin dependency because it'll get replaced with non-cygwin, non-x86 libraries once I target the real device I'm programming for. The configure script won't know how to accept such a statement unless the person who wrote it was *really* forward-thinking, so it took me 30 minutes once to purge a library's Makefiles of no_cygwin statements because they were scattered all over the place. Simple job, made more difficult by the obscurity of Makefiles. I couldn't even do a simple sed on the files because of the way the Makefile was organised.

Why are you blaming Makefiles for how something else generated them? Wouldn't editing the config script have made more sense? Your argument against Makefiles seems akin to complaining about C based on what some generated C looks like (of course we all know it usually looks horrible, and tends to not be representative at all of a typical C program in either style or actually making use of C features)

I dunno, I see how you can be annoyed with the problems you've had and Makefiles are not exactly the most intuitive thing in the world but where possible I much prefer (and don't have much of a problem with) writing them and maintaining one per-port over having any kind of higher level automated system.
 
Last edited by a moderator:
All I can say is that I'm looking at a multi-million lines-of-code project building, right in front of me, using nothing but Makefile's .. as it has been building for the last 20 years, nice and steady, easily ..

If you know how to use them, Makefiles can be a godsend. If you don't, you'll end up screwing things up immensely. The problem is, learning how to really properly use make is a very difficult task; many people assume they can do it and then start complaining bitterly the moment they get tripped up by a single tab char or something .. Makefile magic is definitely something you earn, not receive freely.
 
Sorry, I could have sworn I ticked the 'Enable email notification of replies?' box :huh:

I have come to the conclusion that I hate makefiles and configure files and any other sort of files like that.
Don't get me wrong I think they are fantastic things but I just can't begin to understand it all. One day I will, but today is not that day :p

I ended up just using Code::Blocks (not as fun as just using gedit :p) in the end, it seemed to set up quite easily with Open2x.
I eventually got it compiling for Linux, Windows and the GP2X with the development environment set up on Ubuntu.

Of course I can't figure out how to get Code::Blocks to give me a makefile or anything for releasing on Linux but hey, at least I got the program made lol.

Also I need to sort/test out dynamic linking on the GP2X to make SDL licensing easier lol.
 
p0is0n said:
Also I need to sort/test out dynamic linking on the GP2X to make SDL licensing easier lol.
Using Open2X - just don't compile using -static
The only issue here is your binary will require users to be using the Open2X firmware.
 
Last edited by a moderator:
PokeParadox said:
p0is0n said:
Also I need to sort/test out dynamic linking on the GP2X to make SDL licensing easier lol.
Using Open2X - just don't compile using -static
The only issue here is your binary will require users to be using the Open2X firmware.

Ah, I hadn't thought of that lol. Thanks for pointing that out.
I'm guessing I can't just put the shared object files required next to the game and have it run that way like with dlls?
 
Last edited by a moderator:
p0is0n said:
PokeParadox said:
p0is0n said:
Also I need to sort/test out dynamic linking on the GP2X to make SDL licensing easier lol.
Using Open2X - just don't compile using -static
The only issue here is your binary will require users to be using the Open2X firmware.

Ah, I hadn't thought of that lol. Thanks for pointing that out.
I'm guessing I can't just put the shared object files required next to the game and have it run that way like with dlls?
I think you can use a script to get it to use your local share objects when launching the binary. I'm not too flush with the specifics... hopefully someone can step in and explain if this is possible.
 
Last edited by a moderator:
Thanks for the information.

I will look into this more when I come to releasing the GP2X version, there is just too much information too read through at the moment on accomplishing this.
Maybe I'm just not understanding my obligations of static compiling with SDL properly.
In the license it states that if static linking 'Provide the object or source code to your application along with any libraries and custom tools not available with a standard platform development kit. You may also simply provide a written offer, valid for three years, to provide these materials upon request to anyone with a legal copy of your application.'

While I plan on releasing the source code anyway the part relating to 'custom tools not available with a standard platform development kit.' is the bit I am unsure about.
Would this meant that I would :
a ) Have to link to the open2x website
b ) Have to host the version of open2x that I used
c ) Do nothing other than release my object or source code (which I would be doing anyway)
d ) Do something that I have not listed above

Licensing is fun :(
 
Back
Top