Re: gep-1

[Mark McLoughlin <mark skynet ie>]

Hi Murray,

On 26 Aug 2002, Murray Cumming wrote:

> On Mon, 2002-08-26 at 12:24, Mark McLoughlin wrote:
> > 	Conclusion:
> >
> > 	o Resurrect the idl compilers language module loader (this
> > 	  isn't hard, and I'd be more than happy to do it), merge
> > 	  the branch into HEAD with the c++ bits disabled by default
> > 	  and package the binding seperately from the core.
>
> Let me see if I understand you:
> 1. You want to put the C++ binding into the core, as originally planned?
> 2. But you want to create a separate bindings API or library ("language
> module loader") rather than having the C++ stuff include/link with the C
> code directly?
> 3. You want ORBit2 to not build the C++ by default.
>
> Ignore the following if that was wrong:
>
> a) If you're going to properly separate them (2) then why merge them too
> (1)? You will never really know that they are using only this language
> module loader interface unless you separate them.

	By doing it you 1) reduce the size of the idl compiler in the
default case (admittedly this isn't a big problem since we still
have quite a few thousand lines of code that are unused in there :-),
the mechanism is there for people to play with other bindings
requiring idl compiler support and the main advantage I can see of
merging the binding into the core is that there is a lot better chance
that the binding will be kept up to date with changes to the internals
as those changes happen - if that isn't useful enough to warrant
putting them in the core, then sure, I'd be more in favour of
splitting it out.

> b) Didn't someone have a good reason for removing that language module
> loaders thing when they started ORBit2?

	Don't think so. My guess from looking at the log is that
Elliot disabled it when getting the compiler up and running for ORBit2
and it hasn't been touched since.

> c) I am against conditional compilation. Only the default build will be
> packaged as RPM as debs, so people won't actually have access to the C++
> stuff. I don't have enough confidence that package builders will be able
> to cope with this situation. We need a good reason to make our lives
> this difficult. You seem to have a non-specific fear of the merge, but
> it's hard to justify that given that the branch is there and working and
> people are running GNOME2 with it.

	Yes I know you want it there so that packagers have no choice
*other* than to package them with the core. However, I'm not interested
in *forcing* the availability of the C++ bindings.

> > 	Notice that like Michael, I don't sound convinced either way -
> > this is just the best I can come up with :-)
>
> In the absence of strong arguments, I would choose to stick with the
> plan that we have. It already has working code which demonstrates that
> it poses no threat to ORBit2.
>
> I would prefer complete merge or complete separation, rather than
> something in-between, for the sake of simplicity. And I would prefer
> complete merge because it requires less work.

	Okay fair enough. I would be swayed towards the separation of
the two then. We already have bindings language bindings that rely on
ORBit2 internals (although it should be possible to make the scripting
bindings not do this) so the c++ binding would just become another in
the set.

Good Luck,
Mark.