- Technical Overview
What exactly is Babel's implementation?
Babel has two major parts: a compiler (more precisely a code
generator), and a runtime library. The compiler is written in
Java, and the runtime library is in ANSI C. Some language
bindings also have ancillary runtime libraries which could be
in C or other languages.
What do you mean by "front-end" or "back-end" in the context
of the Babel compiler?
The front-ends are just parsers. We currently have two: a SIDL
parser and an XML parser. There exists at least one case in
our user community of a custom front-end as well. The
back-ends are the (language specific) code writers. The IOR
and XML outputs are also back-ends. Basically front ends
assemble the syntax tree, back ends walk the tree and generate
output.
What's the difference between the Babel distribution and the
Babel-Runtime distribution?
Babel-Runtime is a proper subset of the entire Babel
distribution. In fact, we spawn the Babel-Runtime distribution
from the main tree by executing the commands cd
babel-X.X.X/runtime/; make dist. The entire Babel distribution
includes the code generator, regression tests, documentation,
and examples.
Who would prefer the Babel-Runtime distribution over the
entire Babel distribution?
The Babel-Runtime distribution is the minimal amount of stuff
needed for a 3rd party to distribute their Babelized codes to
a non Babel-savvy customer. Alternatively, someone who
encounters Babelized code and doesn't want to bother with all
of Babel, may find just the Babel-Runtime a suitable option.
Who would prefer the entire Babel distribution over just the
Babel-Runtime distribution?
If you're writing SIDL files or want to generate language
bindings, the entire Babel distribution is clearly what you'll
want.
- Babel configure/build
What tools does Babel use for its configuration/build?
GNU make, Autoconf, Automake, Libtool , Python's distutils,
custom Autoconf macros (in M4), shell scripts, and python
scripts. And plenty of compilers from multiple vendors in a
bunch of languages.
Must I have all languages covered to configure/build Babel
on my platform?
Most languages can be disabled with
the --disable-X flag to the
configure script. This includes every language except C, which
is mandatory (and C++ which almost always comes with C
anyway). For more details, try configure
--help.
What tools do I need to configure/build Babel on my platform?
GNU make, Bourne shell, libxml2, a C compiler and Sun's Java
Development Kit. You'll also need Python if you
do make check. Plus you'll need
compilers for any other language bindings you want your
installation to support. If you're using Fortran 90, you'll
also need Chasm.
What tools do I need to configure/build Babel-Runtime on my
platform?
GNU make, Bourne shell, libxml, and a C compiler. Java not
strictly necessary. Plus you'll need compilers for any other
language bindings you want your installation to support. If
you're using Fortran 90, you'll also need Chasm.
Why is Babel's configure/build so complex?
We're doing something hard and the tools available are not
very sophisticated.
The nature of the problem Babel is attempting to solve - language
interoperabilty - is complex, obscure, and platform
specific. For make check to be
meaningful, we probe the dark corners of language
interoperability issues that most programmmers have learned
to avoid (e.g. character strings in Fortran). Additionally,
Java and Python have separate build systems (or partial build
systems) built into the language itself... which complicates
any external build that tries to manage it. Plus we
compensate when some languages aren't available on some
platforms.
Supporting the build takes an obscenely large percentage of
Babel's development effort. We've even published a technical
report measuring how much it costs us, and investigated if our
costs are commensurate with other projects at LLNL, the DOE,
and even a few large academic projects.
Does Babel require me to use its build system in my application?
Absolutely not. Once Babel is installed, You should only need
to have the babel script in your path to launch the code
generator; have the runtime library headers in your include
path for compilation to succeed; and have the runtime
libraries in your library search path and add the right
libraries on the command line at link time.
If I start using Babel, I'll want to ship Babel in my code
bundle. Then do I have to buy into Babel's build?
No. In that case, you can pre-generate the language bindings
and only ship the Babel-Runtime. You can redistribute the
Babel-Runtime as a subdirectory of your own code, reusing all
of our configure scripts and makefiles therein with minimal
infection of your own build. Of course, your top-level
configure script will have to reference ours, and your
top-level makefile will have to propagate
the all check clean install
targets to our toplevel makefile. To see how this works in
action, simply look at the main Babel distribution,
the runtime subdirectory is
exactly that separable Babel-Runtime distribution.
Babel's build has found a lot of useful information that I
want to reuse in my software. How do I do it?
We would be very interested in exporting as much knowledge as
possible from our build to our customers. The recommended
mechanism is to use
the babel-config script that gets
installed with babel. Type babel-config
--help for information on how to use this tool.
Can I use a parallel make?
Starting with Babel 2.0, you can.
I typed make check an hour ago
and its still going. What's wrong?
Nothing. We do a lot of testing and it can take hours on slow
machines.
Why does Babel's build insist on a specific version of
automake/autoconf/etc.?
Past painful experiences led us to write special autoconf
macros to detect and disable regeneration of build files when
versions don't match. It only cares if you modified input
files to automake or autoconf, and your version of these tools
don't match ours. If you must hand modify any build file to
get Babel working on your platform, then you've discovered a
bug in the build. We strongly encourage you to submit a bug
report to us.
- SIDL
Do you have an EBNF spec for the SIDL Grammar?
Yes, its an appendix in the Babel Users' Guide.
The User Guide's treatment of SIDL is pretty fast and
furious, got anything kinder or gentiler?
At the time this question was asked, we agreed. Since then,
We've restructured the Babel Users' Guide and hope it is more
useful now.
- Babel Code Generator
How do I run the code generator?
If you downloaded the babel-runtime, then you won't find the
code generator. The code generator comes only with the entire
package. The entire code generator is compiled into a single
JAR file, including the DTDs. Babel should install
a babel script which conveniently
sets the appropriate CLASSPATH and launches the JAR file.
What's a "repository" for the code generator?
A repository is a place to store pre-compiled SIDL
files. Using the -R option
in babel adds directories to the
repository search path and functions similar to the way one
uses -I to include header files
in C/C++. It just so happens that this pre-compiled format is
simply XML and can be generated babel using
the --text=xml.
- Language Bindings
Fortran 2003 finally got native C bindings, why still use Babel?
By using Babel you get several advanced features, such as
object-oriented programming and virtual method calls. You can
also save time by letting Babel sort out the right type
declarations for you multi-dimensional
arrays. See README for a more
complete list of features to decide whether Babel is for you.
We also spent a lot of time to figure out the subset of
Fortran 2003 that works on
all platforms/compilers. It makes it also
possible to mix Fortran and other languages like Python,
Java, or Chapel. Babel can even generate the appropriate
Makefile for your platform to link the two together.
Why aren't there (Language X) bindings?
Just because we don't advertise bindings for your
favorite language, does not necessarily mean they don't
exist. Babel's user community has grown to the point where
there are "unofficial" language bindings in the works.
