[Webkit-unassigned] [Bug 128369] [GTK] gtk-doc should not scan the source dir

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=128369





--- Comment #1 from Carlos Garcia Campos <cgarcia at igalia.com>  2014-02-07 03:02:03 PST ---
The problem is not the source dir in the particular case of EWS, but the buildir. What happens is the following:

1.- A patch adding new GObject DOM bindings API is submitted to bugzilla. It's built generating new classes in the derived sources
2.- Another patch is submitted to bugzilla reusing the existing builddir. The new classes generated by the previous patch are still there, but they are not built by this new patch. However, generate-gtkdoc scans the buildir to generate the doc, and it fails when trying to generate the doc of the new classes added by a previous patch and not built.

I have had the same problem locally when I'm working on new classes in a branch, switch to another branch leaving the new classes in my source tree, but not building them, and gtkdoc fails when trying to generate docs for those new clases. Again, because it scans the source tree.

So yes, the problem is that generate-gtkdoc scans the source tree/derived sources dir, instead of receiving the input files from the makefile like all other tools do (gobject-run-api-break-test, gobject-introspection, etc.).

The *only* problem of doing it the right way is that it's more unconvenient to generate the docs manually (currently we only need to call generate-gtkdoc script with no arguments), but we can use a different script to scan the input files, or make the script smart enough to not scan dirs when input is provided. By providing the input files we also avoid all the ugly filters we have to not generate docs for private api/files.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.