Current changelog
Download releases

automake-idl is a patch for automake which adds support for CORBA IDL (C++ ORBs only).



Below, x.y.z is the version of automake and a.b.c is the version ot automake-idl. Here are all the alternative ways to install automake-idl:

  1. Download a prepatched automake source tarball (automake-idl-a.b.c-x.y.z.tar.bz2).

  2. Download vanilla automake (automake-x.y.z.tar.gz) and patch it with automake-idl (automake-idl-a.b.c-x.y.z.patch.bz2).

  3. Checkout from Subversion (the following is a single command):

  4. svn checkout automake-idl

    If you wish to use the current development version then replace tags/IDL-Va-b-c_AUTOMAKE-Vx-y-z with trunk.

  5. Create a patch from Subversion (the following is a single command):

  6. svn diff -x -u > automake-idl-a.b.c-x.y.z.patch

Once you have prepared a patched source directory of automake, build and install it the usual way (you may need to run before configure in cases 2. and 4.).

Finally, you should install autoconf-orb. You should use a compatible version of autoconf-orb.


automake-idl has the following features:

  1. Unification of IDL compiler output
  2. A compilation of an IDL file (e.g. Foo.idl) always produces exactly the following files:
    • Foo.hpp: a header file which contains at least stubs declarations; may include other stub headers
    • FooServer.hpp: a header file which contains both stubs and skeletons (including TIE templates, if the IDL compiler supports them) declarations; may include its stub header and other skeleton headers
    • Foo.cpp: a source file which should be linked to programs which use the stubs; includes Foo.hpp
    • FooServer.cpp: a source file which should be linked to programs which implement the skeletons (should not be linked together with Foo.cpp); includes FooServer.hpp (and thus may include Foo.hpp)
    The generated sources always include the generated headers without a path, no matter if subdir-objects is used or not. This is required because (almost) every IDL compiler has some peculiarity which prevents inclusion of the generated headers relative to the source and/or build directory from working in some situations.

    "At least" above means that the header may contain more but you should not rely on it. For example, omniidl always generates exactly two files:
    • a header which contains both the stubs and skeletons declarations and even some of the definitions (as inline functions)
    • a source file which contains the rest of the stubs and skeletons definitions
    Thus, Foo.hpp & FooServer.hpp will be identical, Foo.cpp & FooServer.cpp - too. But you should not rely on this.

    Do not rely on the special semantics of #include "..." (i.e. including relative to the directory of the processed IDL file) because some of the IDL compilers have problems with it (orbitcpp and TAO for sure).
    Do not use #include <...> in IDL files, even if the included file is not from you package. automake-idl cannot unify the generated sources in this case with some ORBs (Orbix for sure).

    The names of the generated sources can be customized using the following four optional variables:

    So, the four generates sources for Foo.idl would be:

    Here are the default values of the customization variables:

    IDL_HEADER_EXT = hpp

    IDL_SOURCE_EXT = cpp

    See example8 for more info.

  3. Automatic dependency tracking
  4. automake-idl uses the C++ compiler to do this. Currently, only the following automake depmodes are supported:
    If you wish you may modify idldep to support your compiler and submit the patch to the mailing list.
    The automatic dependency tracking may be turned off by the usual means.

  5. subdir-objects
  6. subdir-objects cannot be used to have two IDL files with the same name in different directories because the C++ source files are generated in the current directory and then moved to the subdirectory.
    So, the intended use of subdir-objects is only for cosmetic purposes; don't use it for IDL files namespacing.
    On the contrary - not using subdir-objects is crucial for the multi-ORB scenario.
    See example4 for more info.

  7. Standard targets: clean, distclean, dist, etc.
  8. In contrast to lex & yacc, the clean target removes the generated sources. Distributing IDL-generated sources is pointless, since different ORB's IDL compilers generate incompatible sources.