Skip to content

CompilingRedtamarin

Jump to bottom Edit New page
Zwetan Kjukov edited this page Dec 9, 2015 · 9 revisions

Compiling Redtamarin

As a whole Redtamarin compile a lot of different things

  • the ABC files: builtin.abc, shell_toplevel.abc and redtamarin.abc
  • the Component/SWC file: redtamarin.swc
  • the documentation (asdoc)
  • the C/C++ sources
  • etc.

Building Tamarin

The original build is explained here: Tamarin build documentation.

We are still using it, so you will need those dependencies:

  • Python 2.5 or later
  • GNU make 3.81 or later
    (GNU make 3.80 does not work. Nor does any other brand of make.)

Building Redtamarin

The Redtamarin build is based on Ant and drive many different build systems.

Dependencies and prerequisites:

  • Java 1.6 or later
  • Python 2.5 or later
  • Ant 1.8 or later
  • GNU make 3.81 or later
  • Git and/or Subversion/Svn
  • asc.jar and asc2.jar
    (included in src/utils/)
  • Adobe or Apache Flex SDK
  • a 64-bit Operating System
    the build will work under a 32-bit OS
    but you will not be able to build the 64-bit targets.
  • one or more Operating System Setup

If you want to prepare a machine to compile and test Redtamarin follow our detailed setup

About Repositories

The RedTamarin sources are hosted on a private subversion server: http://dev.corsaair.com

The code is mirrored on Github: https://github.com/Corsaair/redtamarin

The Subversion trunk is always synched with the Git master branch.

Checkout the Code

Checkout the Code with Git

  • open a Terminal
  • go to the work folder
    $ cd /work
  • create a directory
    $ mkdir redtamarin-git
  • enter it
    $ cd redtamarin-git
  • clone the repo
    $ git clone https://github.com/Corsaair/redtamarin.git .

Checkout the Code with Subversion

  • open a Terminal
  • go to the work folder
    $ cd /work
  • create a directory
    $ mkdir redtamarin-svn
  • enter it
    $ cd redtamarin-svn
  • checkout the repo
    $ svn checkout https://github.com/Corsaair/redtamarin/trunk .

How To Build

Configure the Build

From the root of the project

.
├── build
├── build.xml
├── changelog.txt
├── extras
├── license.txt
├── README.md
├── readme.txt
└── src

Go into the build/ directory

.
├── ant
├── common.properties
├── comp
├── compile.properties
├── doc
├── shell
├── targets
├── tasks
├── tpl
└── version.properties

Create your user.properties
$ cp common.properties user.properties

The first thing you need to configure is the path of the Flex SDK
FLEX_HOME_NIX = /sdk/flex/4_6
by default we use the Flex SDK v4.6
but you can use any version
for ex: FLEX_HOME_NIX = /sdk/flex/4_14_1

After that you need to scroll to
#### BUILD OPTIONS ####

Here the main option categories

build.binaries = true
build.documentation = false
build.components = false
build.sdk = false

Each category have more options

build.binaries
compile the redtamarin shell binaries

  • build.32bit = true
    compile 32-bit targets
  • build.64bit = false
    compile 64-bit targets
  • build.release = true
    compile the release targets
    eg. redshell
  • build.debug = false
    compile the debug targets
    eg. redshell_d
  • build.debugger = false
    compile the debugger targets eg. redshell_dd

All those sub-options are accumulable

for example

build.binaries = true
build.32bit = true
build.64bit = false
build.release = true
build.debug = false
build.debugger = false

will produce only 1x 32-bit executable: redshell

another example

build.binaries = true
build.32bit = true
build.64bit = false
build.release = true
build.debug = true
build.debugger = true

will produce only 3x 32-bit executable: redshell, redshell_d and redshell_dd

yet another example

build.binaries = true
build.32bit = true
build.64bit = true
build.release = false
build.debug = false
build.debugger = true

will produce only 1x 32-bit executable: redshell_dd
and will produce only 1x 64-bit executable: redshell_dd

You will find the executables in bin-release/linux
("linux" and/or "windows" and/or "macintosh")

.
└── linux / windows / macintosh
    ├── 32
    │   ├── debug
    │   │   └── redshell_d
    │   ├── debugger
    │   │   └── redshell_dd
    │   └── release
    │       └── redshell
    └── 64
        ├── debug
        │   └── redshell_d
        ├── debugger
        │   └── redshell_dd
        └── release
            └── redshell

note:
with our Hardware Setup
each compilation

  • under Windows
    compiling 1 target take about 16 minutes
    compiling all 6 targets take about 1 hour and 40 minutes
  • under Mac OS X
    compiling 1 target take about 3 minutes
    compiling all 6 targets take about 20 minutes
  • under Linux
    compiling 1 target take about 6 minutes
    compiling all 6 targets take about 40 minutes

Run the Build

From the root of the project
$ ant

By default the build will read common.properties
you can override it by creating a user.properties.

You can also also override specific properties
directly on the command line
$ ant -Dbuild.32bit=false -Dbuild.64bit=true

To run a remote build
$ ssh username@192.168.0.123 'cd /cygdrive/c/work/redtamarin-test; ant'

Windows
To run the build in both 32-bit and 64-bit
$ build/build32and64

Workflow

About Generated Files

Note:
compiling all the binary targets
can take 4 GB of disk space
eg.

bin-debug-32/
├── debug
├── debugger
└── release
bin-debug-64/
├── debug
├── debugger
└── release

Each time you compile any of the binaries

  • we run src/configure.py which generate a Makefile
    for example: bin-debug-32/release/Makefile
  • when we run this Makefile with make
    all the compiled files are generated in the respective
    binary folder, for example: bin-debug-32/release/
  • builtin.abc and shell_toplevel.abc
    are generated (by the make file) in src/generated/
  • many C/C++ files are generated in src/generated/ too
    they are used to embed the native libraries in the runtime

Important:
you can not simply regenerate a new builtin.abc
or shell_toplevel.abc or redtamarin.abc
without compiling the C/C++ source code

and

Important:
you can not generate different versions of builtin.abc
and/or shell_toplevel.abc and/or redtamarin.abc
based on the Operating System

The native libraries (builtin.abc, shell_toplevel.abc and redtamarin.abc)
of the runtimes (eg. redshell) are shared for all the OS supported.

We compile against builtin.abc and shell_toplevel.abc
but we only distribute redtamarin.abc for convenience.

A user code is compiled against redtamarin.abc
but we never include it in the final program.abc
as the bytecode is already embedded in the runtime
by the way of the *.h/*.cpp files in src/generated/.

Making a Pull Request

If you prefer to work with git, you can make a pull request like with any other Github project.

After review, comments etc. if the pull request is accepted here what happen

  • I will grab the patch from .../pull/123.patch into a file 123.patch
  • apply it to the current trunk/
  • test it
  • then create a comment file 123.comment
  • and finally commit/merge into the trunk/

From that point I move into the local git-svn clone
apply the changes
$ git svn rebase --use-log-author
and push back the changes to the git mirror
$ git push origin master

By using --use-log-author, the changes will applied with your Github username

--use-log-author
When retrieving svn commits into Git (as part of fetch,
rebase, or dcommit operations), look for the first From:
or Signed-off-by: line in the log message and use that as
the author string.

In the commits it will appears as "username committed with zwetan From 1ab2c3d4" (username being your user name) and you will appears in the list of commitors.

After that I will close the pull request.

Submitting a Patch

If you prefer to work with subversion, you will need to create a patch.

For example:
$ svn diff redtamarin-svn > example.txt
don't use the .patch extension,
use the .txt extension

From there

  • Create an issue in Github
  • add your example.txt file as an attachment
  • use the comment to describe your patch

After review, comments etc. if the patch is accepted here what happen

  • I will grab the patch from the attachment into a file 123.patch
  • apply it to the current trunk/
  • test it
  • then create a comment file 123.comment
    starting with a "From: username username@domain.com"
    or starting with "From: username" (if you don't provide your email)
    followed by a copy/paste of the Github issue comment
  • and finally commit/merge into the trunk/

example:

From: username

I modified some stuff that do this and that.

From that point I move into the local git-svn clone
apply the changes
$ git svn rebase --use-log-author
and push back the changes to the git mirror
$ git push origin master

By using --use-log-author, the changes will applied with your Github username.

In the commits it will appears as "username committed with zwetan" (username being your user name) and you will appears in the list of commitors.

After that I will close the issue.

Add a custom footer
Add a custom sidebar
Clone this wiki locally