Re: R.I.P., Configure?

[Bill Allombert <allomber@math.u-bordeaux.fr>]

On Mon, Nov 26, 2001 at 04:06:59PM -0500, Matias Atria wrote:
> On Mon, 26 Nov 2001, Bill Allombert wrote:
> 
> > 1) We cannot use libtool, because libtool forbid doing things like putting non
> > PIC code in dynamic libraries, that we cannot avoid until someone volonteer
> > to rewrite all the asm files to use GOT.
> 
> What do you mean by "forbid" ? Is it because of the linker flags used by
> libtool? If you compile .s files without libtool into a .lo file, linking
> with libtool --mode=link fails?

There is no way to avoid libtool compiling shared libs with -fPIC, and we
certainly don't want to do it on i386 and sparc.

> I don't think sacrificing the use of automake is a big deal. But what's
> wrong with VPATH? Most GNU software uses that method to build outside source
> trees and it works fine.

Old make utilities don't support VPATH.
> 
> > 3) We can use autoconf, but it is a bit of works to rewrite the Makefile.SH
> > and the benefit are not clear. [...]
> 
> I would imagine that one of the benefits of having several small Makefile.in
> instead of one big Makefile.SH is that it would make maintainance easier,
> but please correct me if I'm wrong.
You are essentialy right, but note that:
--- We already have several Makefile.SH for each Makefiles.
--- The Makefile.in will be bigger than the Makefile.SH (because programs
generating data are smaller than the data they generate)
--- Part of the code in Makefile.SH will be moved to configure.

However I still consider it would be cleaner to have Makefile.in than
Makefile.SH

> > 4) Autoconf has no support for matching sub architectures to kernel
> > architectures. [...]
> 
> Yes, this is a problem, and my first attempt at a configure script was very
> messy because of this.
Idem. I was sad to see autoconf does not address this.

> Sacrificing libtool would not be too bad either. We would only need one more
> "case $osname-$arch in" to figure out how to produce PIC and link shared
> libaries :-) Or one could do what bash does (or used to do?) which was not
> as fancy as libtool but worked.

libtool has support for loadable module to make install works on all platforms.
Also libtool solve the problem about finding the right option for a given ld.
This is the second biggest problem after the kernel choice problem in PARI
Configure.
This would be nice.  Unfortunately libtool is too broken. 
Creating a library with gcc/GNU ld is more or less platform independent.
PARI build fine on the Hurd, but not old softwares using libtool 1.2
that stupidly fails stating it does not know what is hurd, and new libtool
1.4 is incompatible, so you have to crawl the archive to find the version
1.3.5 which is the first version Hurd aware and the last 1.2 compatible...
Idem for Linux/ia64

I dislike using tools that change interfaces every now and then.

Cheers,
Bill.