This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: initial patch to install libiberty headers
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).
If you look at actual uses, --enable/--disable are the generic hooks
to allow oddball changes that don't fit into any other category, for
instance --enable-build-warnings or --enable-multilib. I've never
heard of --enable being purely an installation controller; at Cygnus
it was always our escape hatch for weird configuration needs.
If you believe all that, then --enable-install-libiberty makes the
most sense.
Stan