This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: initial patch to install libiberty headers
> 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.
We could get by with --enable-install-libiberty if we want to stick
with constructs autoconf already understands.