Re: [PATCH] IDL support for automake-1.5

[Bjørn Wennberg]

"Kyle F. Downey" <address@hidden> writes:

> > 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 omniORB3 compiler can generate c, c++, python and probably
others will be added (such as java). 

The input file stay the same.

The output files will differ from compiler-to-compiler but also
between the taste each programmer have. The omniORB team likes
to name their generated source-file with <file>SK.EXT:

foo.idl becomes => fooSK.cc + fooSK.hh 
nice huh? (SK = Skeleton file)

To complicate it more, a programmer includes the generated header-file
into his or her source-file, so that from the implementation you get:

file_impl.cc:
#include <fooSK.hh>

So at this point you have bound your source-code very tight with the rules
in the Makefiles. This is a point which makes it time-consuming to change a 
idl-compiler (CORBA subsystem). This means again that we might _not_
want to _overfocus_ on portabillity and just pick any idl-compiler from
AM_PROG_IDL


For automake-1.4 I also made a patch (submitted to this newgroup some 
year or two back) that used the following syntax for making omniORB2
compiler work:

macro to check the compiler and set the flags
AM_PROG_IDLC(omniidl2, compiler-flag)

macro to set server-output information
AM_IDL_SERVER(<header-suffix>, <header-ext>, <source-suffix>, 
<source-extension>)

macro to set client-output information
AM_IDL_CLIENT(<header-suffix>, <header-ext>, <source-suffix>, <source-ext>)

That way you should be able to run orbix as:
AM_PROG_IDLC(idl,-A -I. -B -cC.cxx -sS.cxx)
AM_IDL_SERVER(,hh,S,cxx)
AM_IDL_CLIENT(,,C,cxx)

And tao like:
AM_PROG_IDLC(tao_idl,-ss _s.cc -hs _s.hh -hc _c.hh -cs _c.cc)
AM_IDL_SERVER(_s,hh,_s,cc)
AM_IDL_CLIENT(_c,hh,_c,cc)

> 
> > 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.

I don't, at first glance though, think it is possible to achieve 100%
compability using compilers directly in the Makefiles. Using libtool/compile
variants seems to be the only way to solve this.

> 
> 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

And then we have dynamic types for while the IDL compiler will generate
yet-another-source-file of output.

> 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.

Hmm.. I didn't think about that but you are absolutely true :-) Maybe
the file_JAVA_IDL = file.idl, file_CC_IDL = file.idl would cure this?


In a previous mail somone talked about why I made .cpp file by default. I
used to make .cc files (I'm a unix user), but when porting and using
the same files on Visual Studio under MS I couldn't get the system to
acknowledge anything else than .cpp files. *sigh*. Hopefully this
is doable - I just didn't have the time to figure out why.

> 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

automake could supply different checks for finding CORBA compilers such as
this (draft from my project). This exports the following variables that is
in use in my makefiles

OMNIORBINCLUDES = -Iwhatever paths needed
OMNIORBLIBDIR = -Lwhatever paths needed
OMNIORBLIBRARIES = -llib1 -llib2....
OMNIORBCPPFLAGS = -D_REENTRANT -D__OMNIORB3__ etc etc

[snippet]
AC_DEFUN(CHECK_OMNIORB3,
[

AC_MSG_CHECKING([for omniORB3])

AC_ARG_WITH(omniorb3_dir,
[  --with-omniorb3-dir=DIR   use omniORB3 installed in DIR],
[
  ac_omniorb3_dir=$withval
],
ac_omniorb3_dir=/usr/local/omniORB3
)
[snippet]


bjornw>
-- 
------------------------------------------------------------------------
    address@hidden  Bjørn Wennberg, Fifth Season AS