automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] IDL support for automake-1.5


From: Kyle F. Downey
Subject: Re: [PATCH] IDL support for automake-1.5
Date: Mon, 8 Oct 2001 14:50:21 +0000 (GMT)

> foo_SOURCE = foo.cc
> foo_IDL_CC = foo-intf.idl
> foo_IDL_JAVA = foo-java.idl
>

A nit: the point of IDL is that it's the same for all languages, so I
think this is unnecessary.

> The only issue that remains then is whether or not all idl compiler
> support specifying the output extension to begin with.  If not, things
> become even more complicated (especially if there are such compilers and
> they use a different hardcoded extension); it may even be necessary to
> create a wrapper script (a la 'compile' and 'depcomp') to handle such
> things.

It's actually even more complicated.

CORBA support is a huge mess similar to the diversity of UNIX flavors
that led to the creation of the autotools suite in the first place. Proper
CORBA support in autotools would require a new subsystem. It's been a few
years since I was working on CORBA regularly, so I would not trust my
specification for such a thing, but some points to give you a taste for
what's involved in doing it properly:

1) like C compilers, IDL compilers have syntax extensions and support
you'll have to check for with automated tests; worse, since the CORBA spec
has changed over time (particularly with the more recent versions, to
support passing complex types by value), syntax supported will vary by
version
2) like different operating systems, different pre-POA (Portable Object
Adapter--basically this means source-level compatibility for different
CORBA servers) ORBs have different APIs, and so you can't mate CORBA
skeletons created from one IDL compiler to CORBA servers written against
another vendor's APIs. So somehow configure has to either figure out which
vendor's API's were used in the server code itself
3) as Tim pointed out, language support is all over the map in CORBA.
Different IDL compilers will support a mix of C++, Java, Perl, Python and
(for Orbix) even COBOL! Furthermore, you can generate stubs in one
language (a Java client, say) and skeletons in another (a C++ server). You
need to specify in the automake file which you want, and then determine in
the IDL compiler supports the combinations you want.
4) of course at link time, every vendor has a different set of libraries
you need to link in to make it all work, and every vendor on the C++ side
requires building servers as shared objects, so libtool needs to get into
the act as well

--kd




reply via email to

[Prev in Thread] Current Thread [Next in Thread]