[Bug bootstrap/14905] 'make install' fails on grepjar.1, not included in tarball

[kcook at gcc dot gnu dot org]

------- Additional Comments From kcook at gcc dot gnu dot org  2004-04-12 19:37 -------
Subject: Re:  'make install' fails on grepjar.1, not included in tarball [v2]

Alexandre Oliva <aoliva@redhat.com> wrote:
> On Apr 12, 2004, Kelley Cook <kcook34@ford.com> wrote:
> 
> > Now also tested under GCC 3.4 with and without
> > --enable-generated-files-in-srcdir.
> 
> Please be sure to test with and without it both with and without the
> generated files already in srcdir.
> 

I've already done this with GNU make.  Three of them work as expected.

Running a parallel --enable-generated-files-in-srcdir make on a source
directory already containing pregenerated man and info files on a
computer without bison, flex, texinfo, nor perl was a midly interesting
exercise.  Make attempts to copy the sourcedir pregenerated copies to
the sourcedir copies.  cp throws an errors, but due to the "-" in the
make buildrules those errors are ignored.  That seemed like the best
solution in this situation where VPATH bites you.  

Personally, I would think that combination should remain a support-free
option.

> > 	* configure.ac: Parse --enable-generated-files-in-srcdir.
> > 	* Makefile.am: Copy man and info files to srcdir if requested.
> > 	* configure: Regenerate.
> > 	* Makefile.in Regenerate.
> 
> Other than the VPATH issue with Solaris make, that we probably don't
> have to worry about, it looks ok to me.

Over the past few months, I've grown to dislike VPATH.  The concept was
good, but it makes Makefiles very hairy.

> 
> BTW, why are you marking the configure.ac changes as GCC LOCAL, but
> not the Makefile.am ones?

Simple oversight.  I'll add GCC LOCAL to the Makefile.am before
committing.  On the otherhand,  its seems that the upstream of fastjar
is dormant, so maybe the markers are unnecessary.

Mark, OK for 3.4?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14905