Hi Bjorn,
On Wed, May 31, 2000 at 11:22:43PM -0400, Bjorn Wennberg wrote:
> Since different idl-compilers breaks the basename of the idl-file
> in both a) adding a suffix to the filename and b) setting a new
> extention to the file I needed some means of specifying the modifiers.
> Here is the all extensible FAQ :-)
>
> 1. AM_PROG_IDLC(a, b)
> Macro for setting up compiler and option
> a) compiler-program name
> b) options to the compiler
Wouldn't it be better to have the IDL compiler options set in the
Makefile.am files, similar to what is done for C/C++ compilers? I
tend to think something along the lines of the following would be more
consistent with the way autoconf does things:
configure.in: AM_PROG_IDL([optional-list-of-compilers])
IDLFLAGS=-I/usr/include/foo_orb/idl
AC_SUBST(IDLFLAGS)
Makefile.am: AM_IDLFLAGS = -D_FOOBARBAZ
> 2. AM_IDL_SERVER(SK,hh,HEI,cpp)
> Macro for setting server-side output-source-files
> something.idl -> somethingSK.hh
> something.idl -> somethingHEI.cpp
>
> 3. AM_IDL_CLIENT(a,b,c,d)
> Macro for setting client-side output-source-files
> Works like the AM_IDL_SERVER() but is used if server-side
> is different from client-side generated stubs
>
> You could leave some of the parameters blank if your compiler does
> not modify the basename of the idl-file.
IMHO, such a scheme is good for bootstrapping an ORB distribution
since the IDL compiler isn't available at configure time. However,
couldn't automake just examine each of the Makefile.am files for IDL
sources (`.idl'), and then invoke the IDL compiler to determine which
files actually get generated for a given IDL source file. This is
important for some IDL compilers that allow you to change the suffix
(e.g. S -> Ser, C -> Cli). Such a scheme would allow individual
directories to have different suffixes (for whatever reason), and it
would also make it possible for the developer not to have to know
beforehand what suffixes and extensions are used by a given IDL
compiler, thus making the IDL support more transparent.
> automake will add dependencies so that modifying an idl-file will
> automatically run the idl-compiler to regenerate the source-files.
>
> TODO: make maintainer-clean should remove the generated source-files
> and leave the idl files.
Out of curiosity, why maintainer-clean? Shouldn't the distclean
target remove the generated stubs and skeletons instead? Stubs and
skeletons are typically very sensitive to the version of the ORB being
used. If the marshaling/demarshaling engine interface inside an ORB,
for example, changed significantly then any stub/skeleton distributed
with a package would be broken since the internal interface would no
longer be compatible with the one used in the stub/skeleton.
> I guess I've learned more perl since I wrote this patch and someone
> with perl-knowledge would probably clean it up better :-)
One day I'll get past the Bourne shell and learn how to better use
Perl. :-)
Anyway, I like your ideas. Hopefully we, the automake community, can
get moving on IDL support in Automake. It would be extremely useful
for many people, including myself.
Thanks,
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
