Tom Tromey writes:
> >>>>> "Alex" == Alex Hornby <[EMAIL PROTECTED]> writes:
>
> Alex> Is there already an expand_make_variable() type function?
>
> Yes. You can use variable_value_as_list in automake to do this. But
> really you'll want to have direct support for IDL in automake, so that
> IDL files can be listed directly in _SOURCES and be collated by
> automake.
>
> Tom
Hi Tom,
I'd like to get dependencies working before opening another can of
worms :)
Apart from the obvious difficultly of multi ORB setup etc, to keep
clients small it is often desirable to put the IDL client stubs in a
library, keeping the server stubs in the server executable.
Doing this means that you really need better support for generated
sources in general, and would have to further complicate IDL specific
support.
e.g.
# Generalised verision
IDL_HDRS = foo.idl bar.idl
lib_LTLIBRARIES = libfoocln.la
libfoocln_la_SOURCES = $(IDL_HDRS:%.idl=%_c.cpp)
bin_PROGRAMS = fooserver
fooserver_SOURCES = $(IDL_HDRS:%.idl=%_s.cpp) foo_impl.cpp bar_impl.cpp
v.s.
# IDL specific version
IDL_HDRS = foo.idl bar.idl
lib_LTLIBRARIES = libfoocln.la
libfoocln_la_SOURCES = $(IDL_HDRS)
libfoocln_la_IDLCXXFLAGS = --client-only
bin_PROGRAMS = fooserver
fooserver_SOURCES = $(IDL_HDRS)
fooserver_IDLCXXFLAGS = --server-only
IMHO The generalised version is probably of more immediate utility, as
many people would like variable expansion in SOURCES ( only type file
names once :). Also, if your project really is cross-orb (not many
are) you can often get the right behaviour from idl compiler options
and/or with a script similar to compile.
I agree that direct support for IDL is nice, its just not totally
necessary. I think the IDL specific stuff would need to be built on
top of general "built sources" anyway. I'd prefer to do better support
for generalised built sources first. (I've still got the parallel make
stuff on my mind :)
If I get a patch I'll post it :)
Alex.
