[omniORB-dev] RE: [omniORB] Minor patch to windows build

[Harri Pasanen]

On Wednesday 09 April 2003 22:49, Kevin Wooten wrote:

> The problem with this is the idea of platform/compiler combos. If
> you look at omni's current configure.ac, it has macros to test
> obscure parts of the compiler, header locations, type sizes, etc.
> This allows a developer to set CC='some nonstandard compiler' and
> the configure script figures out everything about that compiler and
> goes on with the build. I personally like this feature a lot.
>

I'd say that using autoconf with scons is probably the way to go.  I'm 
also on the scons mailing list, mainly lurking, and I know there are 
some talks about making autoconf replacement, but that is no where 
near prime time yet.

Having 'ported' OmniORB to KCC/HP-UX, and Itanium/GCC, I can say that 
autoconf in practise works quite well, and is a timesaver.   The 
complexity of OmniORB build is however non-trivial, so don't 
underestimate the effort to do a proper job, it will be hours, not 
minutes.  

One of the reasons that has kept me putting me off scons is that none 
of the third party software we integrate to builds support it, 
OmniORB would be the first. I'm all for OmniORB scons support - one 
of the main advantages would be the same system for Win32, and 
parallel build with -j, so Dist CC could be used on Unix platforms.

Note also, that scons has its learning curve and if you are fluent 
with Makefiles, it does not necessary help much.

Anyway, I can probably volunteer some time into testing on Linux,  
HP-UX (PA-RISC, Itanium), Win32.

Harri