Re: initial patch to install libiberty headers

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Mon, Jan 08, 2001 at 05:14:15PM -0500, DJ Delorie wrote:
> 
> > IIRC, the original purpose of --enable/disable was to control whether
> > to install part of a package or not.  That's what I'd use.  IMO, we
> > should arrange for the top-level configure to pass down
> > --disable-libiberty unless it sees --enable-libiberty in the command
> > line, so that libiberty's configure.in can default to having it
> > installed, and then libiberty can be distributed as a stand-alone
> > package, which I consider a good idea.
> 
> I thought --enable/--disable was for whether or not a package was
> *used* in the build, so --disable-libiberty would try to build gcc
> without libiberty (of course, since that isn't supported it wouldn't
> actually do that).
> 
> Similarly, --with-foo tells the package where it can find the foo
> stuff to build with.

Yeah, that was the only reason that plain enable-liberty or with-liberty
wasn't in my previous messages; it doesn't really say what we want to do,
and would give the wrong impression.


> We could get by with --enable-install-libiberty if we want to stick
> with constructs autoconf already understands.

Let's do stay inside that framework.  Extending autoconf wasn't on my list of 
fun things to do today.  :-)

DJ, would there be any serious gotchas in converting libiberty to use
automake?  Just to keep the option open?


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.