- Unification of IDL compiler output
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:
- $(IDL_HEADER_EXT):
the extension for generated header files.
- $(IDL_SOURCE_EXT):
the extension for generated source files.
- $(IDL_CLIENT_SUFFIX):
the
suffix for client (containing stubs) header and source
files.
- $(IDL_SERVER_SUFFIX):
the
suffix for server (containing skeletons) header and source
files.
So, the four generates sources for
Foo.idl would be:
- Foo$(IDL_CLIENT_SUFFIX).$(IDL_HEADER_EXT)
- Foo$(IDL_SERVER_SUFFIX).$(IDL_HEADER_EXT)
- Foo$(IDL_CLIENT_SUFFIX).$(IDL_SOURCE_EXT)
- Foo$(IDL_SERVER_SUFFIX).$(IDL_SOURCE_EXT)
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.
- Automatic dependency tracking
automake-idl uses the C++ compiler
to
do this. Currently, only the following automake depmodes are
supported:
- gcc3: GCC 3
- gcc: GCC 2
- icc: old versions of Intel C++ compiler (actually, exactly
the
same as GCC 2)
- dashmstdout: a generic C++ compiler which supports -M
- dashXmstdout: e.g. Sun C++ compiler
- makedepend: X11
- cpp: a generic C++ preprocessor
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.
- subdir-objects
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.
- Standard targets: clean, distclean, dist, etc.
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.