On Sunday 19 November 2006 07:58, Ralf Wildenhues wrote:
> > Any other suggestions to work around this, than (re-)writing the Makefile
> > rules myself?
>
> Yes. Describe the bug you're seeing. Why does the info file get
> rebuilt if you start from an up to date tarball in a read-only location?
> (If that's the bug you're seeing, that is.)
Ralf,
no, not as such. I am about to add some .texi documentation to gcc/libgomp.
The Installing manual of gcc [1] states: "First, we highly recommend that GCC
be built into a separate directory than the sources which does not reside
within the source tree.".
After bootstrapping languages C and Fortran from SVN, one finds the
following .info files:
$(top_builddir)/gcc/doc/gfortran.info
$(top_builddir)/gcc/doc/cpp.info
$(top_builddir)/gcc/doc/gccinstall.info
$(top_builddir)/gcc/doc/gcc.info
$(top_builddir)/gcc/doc/cppinternals.info
$(top_builddir)/gcc/doc/gccint.info
$(top_builddir)/i686-pc-linux-gnu/libiberty/libiberty.info
None of them is placed in any $(srcdir). Using the Makefile.am snippet from my
last post, I end up with:
$(top_srcdir)/libgomp/libgomp.info
Which is not not go well with the others. OTOH, .pdf, .dvi and html are placed
in $(builddir) which makes .info more equal than the those. This gave the
impression of "a bug". But as Brian Dessent points out:
On Sunday 19 November 2006 03:05, Brian Dessent wrote:
> It's consistent with the fact that the GNU coding standards say that the
> generated .info files should be included in the "dist" tarballs so that
> they can be installed and viewed on end-user systems without
> texinfo/makeinfo installed.
The targets quoted above do not employ automake but maintain the Makefile.in
directly and hence rely on handwritten rules for info, dvi, þdf and html
targets. To be consistent with gcc, but inconsistent with GNU coding
standards, it seems that I have to do the same?!
Ahh, story of my life.
Regards
Daniel
[1] http://gcc.gnu.org/install/configure.html
