[omniORB-dev] SCons, was re: I Want to Port OmniORB to NetBSD

[Kevin Wooten]

[...]
> 
> Unless there is an extremely good reason, I would like to keep the
> current source directory structure. It's too much pain to move things
> around in CVS otherwise. Given that, I think it should be reasonable
> to keep the current build systems in parallel with a SCons setup,
> until SCons is working for (almost) everyone.

Agreed, I just got the structure memorized ;)

> 
> Most of the current ugliness in the make setup is due to trying to
> encode all the platform differences for making shared libraries,
> Python extensions and so on within the make files. Make really isn't
> appropriate for that, so we end up doing all sorts of unpleasant
> things to coerce it. For the next major release, if we don't get rid
> of make altogether, I intend to replace as much of that stuff as
> possible with platform specific Python scripts, so the makefiles are
> much cleaner.
> 
> To answer Kevin's question about replacing autoconf, I think the two
> issues are reasonably orthogonal, so there is no absolute necessity to
> get rid of autoconf if we get rid of make. However, I would love to be
> able to get rid of autoconf. You only have to look at the M4 macros I
> wrote in acinclude.m4 to understand why I'm keen to have a
> replacement. Autoconf has an awful lot of embedded knowledge about
> strange systems, though, so it might be very hard work to replicate
> it. That's especially true given that I don't think there is any
> documentation about what that knowledge is, aside from the autoconf
> source itself. And that's written in M4 and brain-dead bourne shell...
> 

Forgive my lack of knowledge on autoconf, but I thought autoconf was
reasonably tied to automake; I guess this proves it's high time I had
more than just off handed knowledge of it. 

> As for integrating these changes in the omniORB distribution, the 4.0
> branch is closed to everything except bug fixes and very minor new
> features, so I'm not going to mess with the build system there. There
> is already a 4.1 branch (omni4_1_develop in CVS), which is the place
> to experiment with new build systems. Right now, the new branch is
> almost identical to the 4.0 branch (minus a few bug fixes that I
> haven't bothered to merge yet). I'm working on preliminary
> infrastructure for objects by value support, which I'll check in there
> quite soon.

Awesome, patiently waiting...


Kevin