TenDRA Frequently Asked Questions

DERA (formerly RSRE - Royal Signals and Radar Establishment) was, until July 2, 2001, the Defense Evaluation and Research Agency of the United Kingdom. It has since been split into two separate organisations and is now known as QinetiQ. DERA was the logical equivalent of the United States' DARPA.

ANDF stands for Architectural Neutral Distribution Format, a format designed to improve portability and distribution of software. TDF stands for Ten15 Distribution Format (though it has more recently become known just as the TenDRA Distribution Format), and is the base technology selected for the ANDF technology by the now-defunct Open Source Foundation (OSF). There is a wealth of information available at the ANDF Home Page at the University of Karlsruhe, as well as at Martin C. Atkins' Personal Retrospective.

Legend has it that the idea for the Ten15 system, which is at the heart of TenDRA, was proposed at 10:15 in the morning. The Ten15 system was developed by Michael Foster, Ian Currie, Philip Core, et al, at the Royal Signals and Radar Establishment (RSRE, then DERA, now QinetiQ).

CVS: Tried, tested and true. We are aware of the various shortcomings CVS has, but at this point in time, it works, and for our purposes it works well. Most of the above-mentioned alternatives are either lacking in terms of features or maturity. We will continue to revise our opinion on this, and if there is reason to change at some point in the future, we will do so.

One of the most compelling reasons to use these tools is to be able to adapt to different environments on the various platforms out there. TenDRA conveniently divides OS-dependent code into separate files, thus making the autoconf/automake combination an unnecessary added complexity. Additionally, there are unavoidable issues concerning long-time maintenance worries due to incompatibilities, which often arise between differing versions of the above-named tools.

Famous words, once uttered on the tendra-dev list by asmodai@: “A lot of Linux® code requires gmake, we just require this make.”

At this point, TenDRA only contains the bare minimum language support library, not the full standard C++ library. See the C++ producer documentation for more details.

This depends upon the specific issue you are experiencing. The most common issues range from broken standards support on the side of TenDRA or platform of choice to use of compiler-specific features (non-standard features) in the source code. It is prudent to take time to look into possible issues and direct requests to the appropriate place, be it the application author, platform vendor, or the TenDRA team. If you are unsure of where to go, the tendra-help list may be a good place to start. Please consult Google as well as the list archives before mailing the list.

Though there is no support for inline assembly at this time, it is being worked on. For now, we encourage the use of separate .s files combined with .c/.h files instead.

As described in section 3.7 of the C Checker Reference Manual, long long is supported by TenDRA. It is not enabled by default; you may pass -Y longlong to tcc or modify the system description file before building to enable it by default.

The #warning preprocessing directive is a GNU C extension to the ISO C standard and its use, although useful, is discouraged. A proper solution would be to wrap its use with the appropriate #define's for singling out supporting compilers.

TenDRA supports a pragma which allows you to turn on support for #warning's though. By using the following in your code you should be able to use #warning:

#pragma TenDRA directive warning allow
           

For starters, because we like working on it. In the long run, there are interesting prospects in areas such as research, especially due to the nature of the TenDRA compiler; the ANDF technology for instance. Another point of motivation is the fact that TenDRA is a BSD-licensed compiler, which we consider an asset. Finally, everyone has their own reasons, but the above is a fair representation of interests shared by all developers. For more information on the technical aspect that we consider so important, please see the TenDRA Documentation, as well as the ANDF/TDF FAQ entry.

A peek at the task list should give a pretty good picture of what is currently being worked on, or up for grabs if anyone were to be so-inclined. General goals include standards conformance, and research into interesting developments in the world of compiler technology.

A peek at the task list is probably a good idea. See if anything lies within your abilities and take it up. It is a great idea to subscribe to the mailing lists to stay up-to-date on current developments. Let the developers know which area you are interested in contributing to via the appropriate list. We always welcome help!

Familiarize yourself with the TenDRA source that you want to work on, as well as current development. The easiest way to 'get in touch' is to be subscribed to the mailing lists and check out the task list as well. From there, open a dialogue on tendra-dev, and things should begin to take shape. We hope to see your contributions soon!

When creating a patchset, please use diff -ruN or diff -u. Please refrain from submitting uuencoded files, unless the patch is really big, or patches generated with diff -c.

Unfortunately this area is very operating system dependent. It set up so that it works for the operating systems listed under supported platforms, but this is not a cast iron guarantee that it will work for other versions of the same operating system.

Some understanding of how the system works is useful in trying to work around problems. The start-up files describing the macros needed to navigate the system headers for a particular API are found in: src/lib/machines/<os>/<cpu>/startup/<api>.h where <os> is the operating system name, <cpu> is the CPU type, and <api> is the API name. A set of replacement system headers, which are checked before the real system headers, can be found in: src/lib/machines/<os>/<cpu>/include These are also used with the -Ysystem option to tcc, modifications which are specific to library building, should be enclosed in:

#ifdef __BUILDING_LIBS
.....
#endif
         

A good way to look for inspiration on how to customise these files for your particular system is to check how it was done for other systems in similar circumstances. Often a problem crops up on more than one machine - there may be already a workaround implemented for another platform which you can use as a reference.

If you don't intend to re-distribute the TenDRA source code you also have an option which, for copyright reasons, is not available to us. You can copy the system header into the include directory above and make minor corrections directly.

If all else fails you can tell the library building to ignore the header. Find the source file which is failing to compile. This should contain lines like:

#define __BUILDING_TDF_<API>_<HEADER>
#ifndef __WRONG_<API>
#ifndef __WRONG_<API>_<HEADER>
....
#endif /* __WRONG_<API> */
#endif /* __WRONG_<API>_<HEADER> */

         

If you insert the line:

#define __WRONG_<API>_<HEADER>

in the corresponding API start-up file:

src/lib/machines/<os>/<cpu>/startup/<api>.h
         

then the library builder will ignore this header. You will get a compile-time error ("token not defined") if you subsequently try to use one of the features from this header.