[omniORB] omniORB build enviroment

[JohnD.Heintz]

One of the things that I would really like to be able to use is stow on=20
Linux.  This would mean that (at least optionally) the output of make=20
[install] would live in the common bin/, lib/, and include/ directories. =
 The=20
current <platform>/lib structure doesn't work with stow so I end up modif=
ying=20
PATH and LD_LIBRARY_PATH in /etc/profile to help locate omniORB files in =
my=20
install directory.

I am also a user and fan of autoconf if your looking for votes... ;-)

Just my $.02 worth,
John


On Thursday 05 July 2001 12:05, Duncan Grisby wrote:
> I've been thinking about how best to re-work the build environment for
> omniORB 4, and I thought I would get some input about what people
> would like, and any suggestions about how to do it.
>
> The current scheme of manually editing a couple of files is
> inconvenient, and can be quite complex if you have things installed in
> different locations to what the defaults expect. This situation is
> going to get worse as optional things like SSL support come along. We
> really need a "configure" stage. We also don't currently have an
> "install" rule, which I know that many people want.
>
> 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...
>
>  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.
>
>  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.
>
>  4. Something else
>
>
> Does anyone have any comments on any of these?  Even better, if
> someone wants to implement something, that would be great.
>
> Whatever happens, we'll keep the existing build environment in
> parallel with a new system, at least until we're certain that the new
> system works.
>
> Cheers,
>
> Duncan.

--=20
=2E . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com

w w w . d a t a c h a n n e l . c o m