Source Code

From iPodLinux

(Redirected from Svn)

iPodLinux is Free and Open Source software, and as such, all of the source code is available. It is all licensed under some form of the GNU GPL (as far as I can tell).

Nightly Builds

If you can't compile the code yourself:

The iPodLinux software is undergoing constant development. For those who can't or don't want to compile their own, we have nightly builds for certain components. Check the dates on these, if they're more than a year old, you probably don't want to use them.

Nightly builds for the kernel and legacy podzilla can be found on the Downloads page (use alternate download links).
Nightly builds for podzilla 2 (core, modules, and fonts+schemes) can be found on the Downloads page (use alternate download location).

Note: If your downloaded file ends with the extension ".gz", ".tar.gz", or ".tgz" you will need to extract them using a file archiver to obtain the binary files (with no file extensions) and/or folders. If you downloaded podzilla (or podzilla2), rename the file to "podzilla" before you place it into /sbin, and also set its executable file flag, e.g. using the command: sudo chmod +x /sbin/podzilla. Otherwise, see their respective pages for installation instructions.

You can also view an outline of the latest and greatest features, or check the most recent changes to the Subversion tree.

Subversion repository

For some time, iPodLinux's projects were scattered around the Internet. However, somewhat recently all of iPodLinux's projects have all been migrated into a single Subversion (SVN) repository on SourceForge.net.

You can browse the repository online, or check it out with the command:

svn co https://ipodlinux.svn.sourceforge.net/svnroot/ipodlinux/MODULE/NAME

A log of the most recent commits to Subversion is also available online.

All code in Subversion is undergoing active development and liable to change at any moment - it is not an official release. The developers cannot offer end-user technical support for this code, or even guarantee that it works at all at any given moment, and yet, it is the best source at the moment.

Layout

The current Subversion repository has a very different layout than older repositories such as svn.ipodlinux.org or opencsie.org/courtc.

-- /
   |-- apps
   |   |-- desktop
   |   `-- ipod
   |
   |-- legacy
   |-- libs
   |-- linux
   |   |-- 2.4
   |   |-- 2.6
   |   |-- tags
   |   `-- vendor
   |
   `-- uclibc

Hopefully this new layout explains itself.

Linux Kernel

In Subversion we have the iPod-specific patches to build iPodLinux from a uClinux 2.4 based kernel (uClinux-2.4.24-uc0 currently). This kernel is outdated and currently compiles only with the GCC 2.95 Toolchain. You can find a tutorial to compile the kernel at Kernel Building. Work is ongoing to update the kernel for use with newer compilers (see Experimental Kernel for a version that uses uClinux 2.4.32 and builds with GCC 3.4).

-- /linux/2.4/
   |-- arch/
   |   `-- armnommu/
   |       `-- mach-ipod/ - This contains the core drivers for the iPod
   |-- drivers/
   |-- fs/
   |-- include/
   |   `-- asm-armnommu/
   |       `-- arch-ipod/ - The iPod specific include files
   |-- kernel/
   `-- Makefile

Compiling

Source from SVN can be compiled for use on both the desktop and the iPod. You will need to install the 3.4.3 Toolchain if you intend to compile for the iPod.

See Building Podzilla or Building Installer for a complete tutorial.

Developing

Okay, so you've made some changes, and you want to distribute them... that's great. We have a few guidelines we'd like you to follow though;

Do not just immediately redistribute your own version of your executable and source. Please try to follow the proper channels as outlined below.

First, submit your changes as a patch as described below to the developer of the application. For example, changes to podzilla should go to the developer of podzilla. Changes to iPodMame should go to the maintainer of that code base, and so on.

If the maintainer is not accepting patches, fork the source code and executable name appropriately.

Instead of distributing a binary and full source code, it is much easier to provide patches to apply to upstream. This enables developers to incorporate changes or apply patches to future versions.

For modular applications like podzilla2, please try to accomplish your changes through the module interface. podzilla2 allows for just about every aspect of it to be changed via modules. By exploiting this modularity, you don't have to worry about supporting the entire application in perpetuity, nor do you have to re-implement "the wheel" as it were.

naming forks

If your changes are minor; things like a behavioral change or visual difference, do not just take the package and put your own snappy name on it, instead add a hyphen, and a description of the change. For example:

DO:
- If you change the input mechanism for podzilla2, call it podzilla2-SnappyInput or whatever is appropriate.
- If you modify iPodMame to include video output, call it something like iPodMame-VideoOut.
DON'T:
- If you change the input mechanism for podzilla2, don't just call it BleuZilla or something like that.

As far as application names, we prefer that you keep your names differentiated using the hyphen as shown above (podzilla-mz, etc) than completely new personal names. Please do not try to make it seem like your application is the "next step" from one of the core-applications. That is to say that you should not call your application "podzilla3", or "ipodloader7". Consider the base names to be reserved.

Submitting Patches

The rapid advancement of the iPodLinux project is based primarily on user contributions. We welcome any improvements you can make to the project! I'm sure you can subscribe to the patches mailing list and view the archive somewhere.

Please observe these guidelines before generating your snazzy patch. Make sure that your modifications, as well as any new files...

... conform to the Linux kernel style guide - do not change from our style of coding to yours.
... do not contain any proprietary information or non publicly distributable code or data (GPL preferred).
... are adequately commented.
... observe idiosyncrasies (i.e. screen size and color) and scale well between models.
... use standard C99. Generally, we do not accept patches that use C++. We're trying to keep the core software ANSI-C/gnu C99 pure.
- This is a lie, Installer 2 is almost entirely C++
... represent an honest debugging effort, "It compiles! Ship it!" is not a good mantra. If you're testing using the desktop builds, try all of the standard iPod resolution and color depths, etc.
... do not contain unnecessary code changes - reformatting, DOS-style newlines, etc.

Generating the patch

First, make sure that you're working with the most recent version of the SVN repository;

svn up

Next, hand-fix any merge errors.

Now diff all of your changes with the SVN repository, and store the results in a text file. Name the text file something related to what you modified. For this example, we'll assume you added "burrito support", whatever that might be.

svn diff > ~/burrito_patch.diff

This will catch any changes made between when you checked out the files from Subversion repository and the way they currently stand.

If you only want to diff one file, and not your whole folder -- for instance, if you are working on other files and you don't want that work to be included into your patch as well -- you can specify your file:

svn diff burrito.c> ~/burrito_patch.diff

Any new files you have created will not be contained in the above, so we need to add them onto the patch file like so:

diff -u /dev/null my_cool_new_file.c>> ~/burrito_patch.diff
diff -u /dev/null my_cool_new_file.h>> ~/burrito_patch.diff
etc...

Applying a patch

If you happen across a patch you want to try out, first update your SVN directory, then apply the patch like so:

patch -Np1 < /path/to/patch.diff

If the patch happens to be compressed:

bzcat /path/to/patch | patch -Np1

If you get errors like "missing header for unfiled diff at line 8 of patch" then try the following parameters instead:

patch -Np0 < /path/to/patch.diff

You should 'make clean' before applying the patch, to kill any straggling files that might not be current.

Personal tools

Views