automake-idl
Current changelog
Download releases


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


Installation
Features




Installation

First, you should install autoconf-orb. You should use a compatible version of autoconf-orb. You may recognize compatible versions by comparing the release dates - they should differ by no more than a day or two. In the future (after an 1.0 release) automake-idl and autoconf-orb will keep their versions synchronized.
Below, x.y.z is the version of automake, 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.bz2) and patch it with automake-idl (automake-idl-a.b.c-x.y.z.patch.bz2). Make sure to use patch -p1 inside the automake-x.y.z directory.

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

    4. cvs -d :pserver:anonymous@autotools-idl.cvs.sourceforge.net:/cvsroot/autotools-idl checkout -R -r IDL-Va-b-c_AUTOMAKE-Vx-y-z automake-idl

    If you wish to use the current development version then omit the -r IDL-Va-b-c_AUTOMAKE-Vx-y-z option.

  4. Create a patch from CVS (the following is a single command):

    5. cvs -d :pserver:anonymous@autotools-idl.cvs.sourceforge.net:/cvsroot/autotools-idl rdiff -u -r AUTOMAKE-Vx-y-z -r IDL-Va-b-c_AUTOMAKE-Vx-y-z automake-idl | bzip2 -9 > automake-idl-a.b.c-x.y.z.patch.bz2

    There may be certain combinations of automake and automake-idl versions which have not been released, i.e. you can get them only from CVS. To see what combinations of versions are possible, see what tags in the form of IDL-Va-b-c_AUTOMAKE-Vx-y-z are avalilable for automake.in:
    • WebCVS
    • Checkout the main branch of the automake-idl module (i.e. without an -r option) and issue the following command in the main directory of your local copy (the following is a single command):

    cvs log automake.in | grep 'IDL-V.*_AUTOMAKE-V.*' | sed 's/^.*\(IDL-V.*_AUTOMAKE-V.*\):.*$/\1/'
Once you have prepared a patched source directory of automake, build and install it the usual way (you may need to run bootstrap before configure).



Features

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 Makefile.am 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
    IDL_CLIENT_SUFFIX =
    IDL_SERVER_SUFFIX = Server

    See example8 for more info.


  2. Automatic dependency tracking
    3. 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.


  3. subdir-objects
    4. 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.


  4. Standard targets: clean, distclean, dist, etc.
    5. 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.