> configure.in: cannot disable the use of gtk-doc when configuring.

Where did you get that output from?
Please provide us some lines of output,
see 5 lines above and 2 below the error line.
(right now, with the terse information, I can't recognise it)

It's not a output! :)
I don't have gtk-doc on my system, and I'm not able to disable its use
in order to compile conglomerate. It's a configure.in and/or
makefile.am issue... I tried to fix it, but it seems trickier than
expected, I droped the case coze don't have time...

gtk-doc stuff is for the time being disable.
We should have done this before or implement gtk-doc better.
thanks for reporting the inconvenciance
your feedback resulted in bug 136100

Merci

Leave this bugreport open until a proper gtk-doc disable exists.
The component GENERAL is a good choice, however I change it into
DOCUMENTATION for easier references.

Sorry, the feed back resulted in bug 131600

From the conglomerate-devel mailinglist
 ( http://lists.copyleft.no/pipermail/conglomerate-devel/2004-June/002787.html )

>I did some hacking on this over the weekend; ultimately it turned out
>that for "make distcheck" to work, gtk-doc has to be installed on the
>build machine, and the configure script has to default to having gtk-doc
>on.  The abbreviated test above defaults to disabling gtk-doc.
>
>So I fixed the verbose version of the test to use "auto", and "make
>distcheck" now works (provided I've done two "makes" in the tree
>previously...)  I added a comment on this into the CVS version of
>configure.in
>
>So... it works!
>
>Dave

Yes that is the situation - default check macros for gtk-doc conflicts with
default Makefile for the gtk-doc (gtk-doc.make).

Dave, today I was trying to build rpm from new release. Build fails on gtk-doc.
So, the change of gtk-doc to auto was to hasty.

And my (-: not so ;-) humble opion that no gtk-doc is better
than a tarball, or CVS tree, that fails to build.

Enforcing gtk-doc tools for optional documention is also evil...

In bug #148382 you can read:

| C) We've seen many, many failures from screwed up XML/SGML 
|    configurations of one sort or the other. There's absolutely
|    no reason to make people debug them, or for that matter,
|    wait 10 minutes for docs to build, when we can ship tarballs
|    with the docs already there.

So conglomerate seems to ship tarballs with incomplete/wrong/broken/whatever
gtk-doc.

Hu? Why to reopen it. It tried to compile conglomerate 0.9 with a gtk-doc free
system and it was fine. Did I miss something?

The 'close bug' action was some what silent ;-)
so I reopened also silent.

Now that there is text that it works,
closing the bug this verbose way.

TNX