[haible@ilog.fr: [patch] make install]
Craig Burley
burley@gnu.org
Tue Jan 20 09:08:00 GMT 1998
> In message < 199801071751.MAA23957@melange.gnu.org >you write:
> > [Is this a reasonable thing for language to do, in general? If so,
> > it might be worth considering for all of them.]
> >
>[ ... ]
> > When I take the full egcs snapshot, configure it in a separate directory,
> > change the LANGUAGES line in the Makefile to not include "f77", then
> > "make" will succeed but "make install" will fail because it tries to
> > install the nonexistent file "f/g77.info*". Here is a fix:
>I don't think we want to try and deal with this that late in the
>configure/build process.
>
>I'd prefer we have some option to disable a language that exists in
>the source tree. ie -- --disable-fortran or some such.
>
>Other thoughts?
I'm not sure offhand if "make LANGUAGES=... bootstrap", for example,
implies that "make LANGUAGES=... install" must be done.
But, I don't know offhand why we can't make mistakes like this
pretty easy to work around.
The patch, as submitted, is not quite right though, because it
*first* removes the system's, installed (g77) documentation,
*then* checks to see whether it has anything to put in its place.
Hmph. ;-)
I've already incorporated this patch in the gcc-2.7.x-based g77
(that will become 0.5.22) with some improvements, and was planning
on submitting a corresponding improved version of the patch for
egcs. (The relevant chunk of makefile is different between the
two versions, so I can't just throw the 0.5.22 version at you.)
Let me know whether you think this is a bad idea for some reason.
One thing I noticed long ago, and have lost track of as an
issue, is that some GNU products treat "make install" as,
essentially, the same thing as "make all" followed by "make
install". That is, installation is assumed to pertain to the
entire product, so anything not already built is built. But,
other GNU products interpret "make install" to mean "install
whatever I have already built", so nothing new is built. I'm
not sure which is best offhand, but for products that offer
dynamic specification of which *components* of a product to
build, the latter has some advantages.
tq vm, (burley)
More information about the Gcc
mailing list