Re: ORBit2 parallel install fixes

[Mark McLoughlin <mark skynet ie>]

Hi Havoc,

On 17 Sep 2001, Havoc Pennington wrote:

> > 	* The namespacing of the headers to ${includedir}/orbit-2.0 is
> > 	unneccesary, I think. ORBit-0.5.x headers reside in
> > 	${includedir}/orb and ORBit2's in ${includedir}/orbit.
>
> I believe we need it for ORBitservices and orbit-idl2.h anyway.
>
> The reason I would advocate using orbit-2.0 for all of it is that the
> strategy of s/orb/orbit/ clearly doesn't scale to orbit3. ;-) It's
> nice and clean to just put everything in orbit-1.0 for orbit1, in
> orbit-2.0 for orbit2, etc. But a matter of taste, just tell me what
> you prefer, especially for ORBitservices and orbit-idl2.h

	Ahh relax - we've always got ${includedir}/ORBit ;)

	Seriously, though - I don't think the change is needed and
would be more trouble than its worth.

	orbit-idl2.h, hmm, I don't think we should be installing this
for the moment. For one thing it includes headers that *aren't*
installed. For another, I'm not even sure if idl compiler backends are
working.

	ORBitservices - I think these should go into orbit/services if
no-one has objections. Oh, and there seems to be an IDL file in
there...

> > 	* I wonder can we kill the ORBIT2=1 define?
>
> What does it do?

	Anyone? I think nothing - maybe it had something to do with
ORBit-martin-forked. I'll look at it soon.

> > 	* Can we try an solve your poa IDL_DIR problem seperately?
>
> I had no idea how to address this; I think the Makefiles are a bit...
> over-creative. ;-) I don't have time at the moment to reengineer the
> ORBit2 build, so I will probably just move this patch to the spec file
> if you don't want to clutter things in CVS. Or if there's another
> simple fix you can think of I'm happy to use it.

	I fixed some bugs with the IDL dependancy tracking etc. - I'd
wager that the problem is gnome now ;)

Cheers,
Mark.