Here is what you need to know to get started with XL:
Today, the best way to get an up-to-date version of XL is to directly fetch the source code using git.
% git clone git://xlr.git.sourceforge.net/gitroot/xlr/xlr
The source code contains two top-level directories:
xl2directory contains the front-end for the statically-compiled XL2 programming language.
xlrdirectory contains the dynamic XLR programming language
These two components can be built independently.
The compilers are currently only provided in source form. You need to build them before being able to write an XL program.
Once the compilers have been built, you can test them. In addition to verifying that the compiler works as intended, test programs provide a good source of examples.
Alternatively, you can also download it from the SourceForge downloads page. However, the packages placed there tend to be stale. This entry will be updated when any files worth mentioning will be posted there.
The XL distribution contains two top-level directories:
To build the XL2 compiler, go to the
xl2 directory and type
% cd xl2 % make
This will perform a compiler bootstrap. In other words, several compilers will be built successively:
xl, written in C++, and compiling a simplified version of XL2
bxl, written in simplified XL and compiled with
xl, and implementing a slightly less simplified version of XL.
bxlcompiles itself several times, resulting in compilers called
nxl, compiled with
bxl, written in bootstrap-level XL, and implementing the full XL2 semantics.
The bootstrapping process is not perfect, because it proved difficult to keep the language compiled by
nxl compatible with the simplified idiom accepted by
bxl. As a result,
nxl can only compile itself with the
-bootstrap option, which make it accept a very sloppy variant of XL2.
To build the XLR compiler, go to the
xlr directory and type
% cd xlr % make % make test
The XLR language is still under active development and may change rapidly.
Building XL assumes that you have developer tools installed:
makethat is not too incompatible with GNU make.
The code has been mostly tested with the GNU GCC toolchain, although you may be lucky with other compilers.
Before building XL components, you may want to set the
BUILDENV environment variable, for example:
% export BUILDENV=macosx
The syntax for setting
BUILDENV may vary with your shell. Currently, the reasonably tested choices for
macosx for MacOSX (tested on 10.6)
linux for Linux builds (tested primarily on Ubuntu and Fedora)
mingw for Windows using [MinGW]
The environment variable is used to pick a makefile configuration, which is stored in a file named
xyz is the value of
BUILDENV. You may easily create your own build environments by modifying one of these files, for example to use Intel compilers instead of GCC on Linux.
BUILDENV variable is not set, the build system will try to guess a best choice for your platform, and emit a message like the following:
The BUILDENV environment variable is not set You will accelerate builds by setting it as appropriate for your system. The best guess is BUILDENV=macosx Attempting to build debug with macosx
This message indicates the best guess of the build system for your particular platform.
To build an optimized compiler, use:
% make opt
To build a debug compiler (currently the default), use:
% make debug
To show the command lines being used during build, prefix the build target name with
v- (for verbose)
% make v-debug
To measure how long the build takes, prefix the build target with
% make timing-debug
To run the various tests for a given components (the rule is not always present)
% make test
Here are some places where you can get some help about XL:
There are also two obsolete mailing lists that were, unfortunately, spammed to extinction.
|XL programming language and runtime|
|Visit this group|