[omniORB] omniORB build enviroment

[Lars Immisch]

Hi,

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

I'd like a realclean (or a veryclean) rule in every makefile to get rid of all  
dependency files.

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

I've never written any autoconf from scratch, but I've modified existing  
autoconf environments, which was not difficult. Maybe it's best to learn from  
an example.

For NT and autoconf, a fairly typical approach is to supply a config.h.nt and  
a global.mk.nt or rather config.mk.nt and people on Windows have to copy them  
to config.h and config.mk instead of running configure.

They have to have cygwin installed, of course.

Most people on NT would probably like MSVC project files, but having two build  
systems in parallel is a mess and highly unpractical unless you are using them  
yourself heavily.

This could be done by a volunteer however and you could supply them with a  
warning that they may be out-of-sync.

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

Hmmm. Maybe I misunderstand things, but this is what autoconf would do. If you  
want a build system, you'd have to look into automake, I think.

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

But you'd still need /bin/sort instead of sort.exe on Windows, wouldn't you?

- Lars