[omniORB] omniORB build enviroment

[Kevin Bailey]

On Thu, Jul 05, 2001 at 06:05:43PM +0100, Duncan Grisby wrote:
> 
> So, there are a few options I can think of:
> 
>  1. Autoconf
> 
>     This would fit with Unix (especially Linux) users' expectations of
>     being able to do a simple "configure; make; make install" and
>     have everything work. However, autoconf assumes a Unix-like
>     environment, so it leaves problems for other platforms. Also, I've
>     read the autoconf documentation and I don't understand it in the
>     slightest...

I don't know how much it would help but if you described the
project to kdevelop, it will automatically generate autoconf
configuration for you. It'd be a fair start anyways.

Regarding other platforms, you can tweak the configure script that
autoconf generates to allow it to find out what it needs using a
more generic procedure.

This option would be really cool because you'd automatically
pick up all the neat things autoconf'd config files can do.

>  2. A configure stage to the existing build system
> 
>     We could have a Python script which automatically wrote the
>     configuration files required by the current build environment.
>     This would be relatively simple, but the current build is getting
>     pretty complex, so it might not be that easy in the long term.

I vote for this one (or autoconf) assuming it supported the same
options as a common configure script (--prefix, --with,
--enable, ...)

It shouldn't get that complicated. It's job should only be to
discover, for example, how to evoke the C compiler. Your build
system would hopefully still be makefiles.

If you have something so complicated that the configure scripts
must create makefiles, perhaps autoconf will actually save you
work.

>  3. A Python script which builds everything
> 
>     The most radical approach is to write a complete new build system
>     in Python, replacing make as well as the configuration stage. The
>     Software Carpentry competition (software-carpentry.codesourcery.com)
>     aimed to create new tools to do this, but it doesn't look like
>     there's anything particularly useful to be had from there. This
>     would be a lot of work, but it might result in a tool which is
>     useful beyond omniORB. It would also make life easier for Windows
>     users, since the gnuwin32 tools wouldn't be necessary anymore.

Something like this may hurt people who prefer their own tools,
such as a parallel make. Everyone has make, right ?

Also, I can't imagine writing an entire build system would be
easier than learning autoconf. ;)

The main thing I'd like to see out of the omniORB  build system
is the ability to compile/create the object and other files in a
different location than the source. Currently omniORB compiles
in place. This makes compiling for 2 platforms at the same time
hard. We are having to copy the entire tree to 2 other places
(via links) in order to accomplish this.

autoconf configure scripts do this out of the box. You just go
to another directory and enter:

<path to configure>/configure <options>

and it builds everything there. This might have other uses such
as building off a read-only file system.

-- 
"That's a chapter, the last chapter of the 20th, 20th, the 21st
century that most of us would rather forget. The last chapter of
the 20th century. This is the first chapter of the 21st century.
"-George W. Bush, On the Lewinsky scandal, Arlington Heights,
Ill., Oct. 24, 2000

Practice thinking before speaking.