Running into this problem when using jhbuild too.

manually copying tools/gnome-doc-utils.make to the top-level source directory allows it to work properly.

The reason for this is the following.

gnome-common's gnome-autogen.sh looks in every file listed in

configure_files="`find $srcdir -name '{arch}' -prune -o -name '_darcs' -prune -o -name '.??*' -prune -o -name configure.ac -print -o -name configure.in -print`"

for the pattern ^GNOME_DOC_INIT, and if it finds it, it assumes g-d-u is wanted by the package being autogen.sh'ed and runs g-d-prepare. 

In the case of g-d-u itself, both $(srcdir)/sandbox/mallard/configure.in and $(srcdir)/test/testdoc1/configure.in include that pattern, so g-d-prepare is run *after* the vain attempt of g-d-u's autogen-sh of copying $(srcdir)/tools/*.{make,m4} to $(srcdir).

A hack would be to move the two cp commands in the autogen.sh script to *after* the gnome-autogen.sh script is run. An ugly hack.

Created attachment 76872 [details] [review]
A slightly less hacky dix

This patch depends on the patch I just posted on bug 377175.

It uses a proposed CONFIGURE_FILES environment variable to be explicit about which configure.in files autogen.sh should scan.

Damn.  So here's how this happened: gnome-doc-utils used to use its own custom gnome-autogen.sh with the g-d-u bits cut out.  But then I was missing changes to gnome-autogen.sh.  So instead, I changed gnome-doc-utils.m4 to define GNOME_DOC_INIT and GNOME_DOC_DEFINES.  GNOME_DOC_DEFINES does all the defines, but without the version check.  And since it doesn't match gnome-autogen.sh's grep, I could put it in configure.in.

Mariano, the approach using CONFIGURE_FILES seems relatively sane to me.  The approach from comment #2 would still create a problem when building gnome-doc-utils for the first time, because gnome-autogen.sh would try to call gnome-doc-prepare, which won't exist on the system yet.

If bug #377175 gets resolved, you have permission to commit this.  If we could also somehow specify a version of gnome-common required, that would be great.

Created attachment 77529 [details] [review]
Updated patch

This patch is an update to my renaming of the envvar in the gnome-common patch.

Also, from talking to jamesh on irc, it appears the following is expected to work:

cvs co gnome-doc-utils
cd gnome-doc-utils
mkdir build
cd build
../autogen.sh

Currently this does not work for g-d-u: this updated patch fixes one issue: the Makefile.am's in g-d-u should not include $(srcdir)/gnome-doc-utils.make because that will not exist in a build as the one above, so the patch adds a couple of /tools/ to get the existing file.

This is not enough: but I cannot see how to fix this srcdir!=builddir build, as there is some indirection which is getting broken and which I do not understand: the build goes ok until one hits the following (tt is my build directory):
 
Making all in doc
make[1]: Entering directory `/elsewhere/GNOME/src/gnome-doc-utils/tt/doc'
Making all in gnome-doc-make
make[2]: Entering directory `/elsewhere/GNOME/src/gnome-doc-utils/tt/doc/gnome-doc-make'
xsltproc -o gnome-doc-make-C.omf --stringparam db2omf.basename gnome-doc-make --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.4//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir "/usr/local/share/omf" --stringparam db2omf.help_dir "/usr/local/share/gnome/help" --stringparam db2omf.omf_in "`pwd`/../../../doc/gnome-doc-make/gnome-doc-make.omf.in" --stringparam db2omf.scrollkeeper_cl "`scrollkeeper-config --pkgdatadir`/Templates/C/scrollkeeper_cl.xml" ../../../xslt/docbook/omf/db2omf.xsl ../../../doc/gnome-doc-make/C/gnome-doc-make.xml || { rm -f "gnome-doc-make-C.omf"; exit 1; }
make[2]: Leaving directory `/elsewhere/GNOME/src/gnome-doc-utils/tt/doc/gnome-doc-make'
Making all in xslt
make[2]: Entering directory `/elsewhere/GNOME/src/gnome-doc-utils/tt/doc/xslt'
gawk -W compat -f "../../../doc/xslt/xsldoc.awk" "../../../xslt/docbook/common/db-chunk.xsl" | xsltproc -o "C/db-chunk.xml" --stringparam basename "db-chunk" --stringparam xsl_file "../../../xslt/docbook/common/db-chunk.xsl" "../../../doc/xslt/xsldoc.xsl" -
warning: failed to load external entity "../../../../xslt/docbook/common/db-chunk.xsl"
db-chunk: No stylesheet param for documented db.chunk.chunks
make[2]: *** [C/db-chunk.xml] Error 10
make[2]: Leaving directory `/elsewhere/GNOME/src/gnome-doc-utils/tt/doc/xslt'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/elsewhere/GNOME/src/gnome-doc-utils/tt/doc'
make: *** [all-recursive] Error 1

Hum, if we're just going to include the gnome-doc-utils.make in tools, we probably don't need to copy it to the top-level build directory.

As for the error, I think we just need to add some $(srcdir) action to the files being passed on line 18 of doc/xslt/Makefile.am.  I'm surprised I didn't catch this problem when running distcheck.

I can confirm than this bug is still present in HEAD.

And I'm still getting build failures:

http://jhbuild.bxlug.be/builds/2006-12-20-0008/logs/gnome-doc-utils/#configure

Looking into it further, CONFIGURE_AC_FILES=$srcdir/configure.in doesn't work because gnome-autogen.sh ignores that variable and uses the following to determine configure_files:

configure_files="`find $srcdir -name '{arch}' -prune -o -name '_darcs' -prune -o -name '.??*' -prune -o -name configure.ac -print -o -name configure.in -print`"

which then finds GNOME_DOC_INIT in gnome-doc-utils/test/testdoc1/configure.in and ./sandbox/mallard/configure.in.

James, that is preciselñy why I said that «This patch depends on the patch I just posted on bug 377175»

Please do not add comments to open bugs that have been confirmed only to say «I am still seeing this», as, unless the bug is marked FIXED, that is to be expected. If the bug gets marked FIXED but you still see it, _then_ let the world know. We already get much bugmail as it is! ;-)

This has been resolved in #377175 by making gnome-autogen.sh skip configure.(ac|in) files in directories with a NO-AUTO-GEN file.

*** Bug 386599 has been marked as a duplicate of this bug. ***

It should be noted that this only works if your definition of ‘works’ allows for the autogen.sh script in, say,  gnome-doc-utils/sandbox/mallard to fail because there is no configure script...

I'm not so concerned abuot that directory being unbuildable right now, as it's not part of the actual package, and I'm going to change its contents fairly drastically soon anyway.