Re: R.I.P., Configure?

[Matias Atria <atria@math.upenn.edu>]

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?

> 2) We cannot use automake, because there is no support for libraries outside
> libtool. Also automake does not support splitting source code in separate
> directories. Also there is no direct support for putting object files in a 
> separate directory, [...] Automake only support VPATH.

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.

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

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

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.

Cheers,
Matias.