[openib-general] Re: [ANNOUNCE] userspace/management now partially uses autotools

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <halr at voltaire.com>:
> Subject: Re: [ANNOUNCE] userspace/management now partially uses autotools
> 
> On Sun, 2005-01-30 at 06:06, Michael S. Tsirkin wrote:
> > For now, we have a huge step backwards.
> 
> I don't agree with your qualification of this as huge.
> 
> > I quote the README file:
> > 
> > > To make this tree,
> > > 1. In libibcommon, libibumad, and libibmad (in that order), run:
> > > ./autogen.sh && ./configure && make && make install
> > > 2. In all util and diag subdirectories, run:
> > > ./autogen.sh && ./configure
> > > 3. At top level of management, run:
> > > make && make install
> > 
> > 
> > Hal, currently this means that
> > 1. its painful to build opensm
> >    Several manual steps are required.
> 
> This is only temporary.

I understand, but could not the check-in wait till its working?

> > 2. The process differs from the standard configure/make
> 
> How ?

need auto-tools.

> >    I think generated configure files shall be checked in so that
> >    the process is less painful for most people.
> 
> I did the same thing as was done in the other userspace directories.

Sure, but so far opensm is the only tool I know that depends on such a
lot of libraries, so its lett painful there.

> > 3. Current build requires that libraries are *installed*
> >    before opensm is built.
> >    This means that I cant have two versions installed without
> >    manual tweaks, and that just to *check* if some problem I have is fixed on
> >    trunk, I must install newer libraries possibly breaking a
> >    perfectly good installation.
> 
> The newer libraries are only required if there are changes in them.

Like, libumad? :)

> This is the way the other userspace libraries are done.

There are tools (vim) that have a configure flag to tell them
which library version to use:local or system-wide.
Others (like gcc) will check whether they reside in the same tree
with the libraries, and if so link against them.
Subversion code I think defaults to in-tree libraries if found,
and supplies a flag to override it.

> If it is consensus to remove the installation dependency, this is
> straightforward to do.

I think at least an option would be nice.

> > May I suggest such changes shall be checked in
> > when they are fully ready (when all the tree has been converted)
> > and not half ready?
> > Alternatively, put them on a branch.
> 
> I'll convert it back if that's what people want. It's pretty simple to
> do. You can do this in your own tree if you don't like the way it is.
> 
> -- Hal
> 

Dont get me wrong, I'm not against configure/make as a method,
I think generally its good to standardize the build and you are going
in the right direction with this with using standard configure/make
commands.

Cheers.

-- 
MST - Michael S. Tsirkin