Morten Eriksen wrote:
>
> [Oops, I forgot to Cc: the list when replying to Jan.]
>
> * Jan Prikryl
> > Another question: some time ago, Morten Eriksson from SIM thought
> > about providing an automake/autoconf support for the Inventor code
> > [...]
>
> I'm sorry I never got around to completing this, I had made it through
> libimage and 3/4 or so of the way through libInventor when other tasks
> at hand got higher priority for me.
... I have partially ported the apps, doc and libSoXt
subdirectories. Not good enough to make them public, but sufficient
for me :(
> > ... I suppose it is not a trivial thing to set up, and probably
> > better done by a single developer, but if I could help somehow (the
> > current makefile system drives me nuts sometimes).
>
> I discovered a couple of things, though:
>
> I think the first thing the SGI maintainers need to do is to split up
> the single monolithic CVS module into several pieces. One for
> libimage, one for libInventor, one for libInventorXt, one for the
> tools, one for the examples, etc etc.
>
Fully agreed.
> Before this is done, completely converting to
> autoconf/automake/libtool for configure and build would probably make
> the setup complex enough that it would look like a lot more mess than
> the current Makefile-based build.
Well, I am inclined to agree, when regarding this topic from a
puristic auto*-tool's point of view, but IMHO, there are fairy
simple ways to provide a gradual transition to auto* tools.
Eg. one possibility is to start with a toplevel configure script to
setup the standard auto* installation variables (prefix, mandir
etc.) and to configure the SGI's build-configuration files below
make/ and build/.
I.e. to propagate auto* variables to the GNUmakes through SGI's
configuration files.
This way most of SGI's GNUmakefiles could be kept without (major)
changes, but the whole package would gain major flexibility wrt.
installation.
This approach also would avoid the deficiencies the current versions
of the auto*-tools have wrt. C++, because this configuration scheme
would not apply these, but would still rely on SGI's config files +
some (IMHO: significant) amount of additional flexibility.
>
> Another important aspect is that the current releases of autoconf
> (v2.13, I think) and automake (v2.14?) is getting really long in the
> teeth and is a far cry from matching the state of these tools fresh
> from CVS. So it might be better to hold off a bit anyhow, until
> autoconf v2.50 and the next automake release happens.
I know that you are using them for your development, I am using them
myself and I know about the advantages of the new versions, but I
don't share your opinion.
The new versions of the auto*- tools would be useful if full
flexibility and portability is objective and would partially ease
applying the auto*-tools, but even using the current versions of the
auto* tools would not be worse than the current configuration scheme
in SGI's OIV, IMHO.
Ralf
--
Ralf Corsepius
Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung
(FAW)
Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690
mailto:corsepiu@xxxxxxxxxxxxxx FAX: +49/731/501-999
http://www.faw.uni-ulm.de
|