SCons, was re: I Want to Port OmniORB to NetBSD

On Wednesday 9 April, "Zed A.Shaw" wrote:

> The question is though, do you want a scortched earth policy where I 
> completely abandon the old build system when I make the new one?  If I 
> can abandon the old one, then everything will be nice and clean, but 
> you might lose some people on some platforms temporarily.  If you keep 
> the old one, then you can provide a nicer migration path for those who 
> can't do the SCons build.

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.

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...

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.

Thanks to both of you (Zed and Kevin) for your interest in helping
with these issues.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --