Re: More fun with dependencies in gtk-doc



Peter Williams <peter newton cx> writes:

> Hi Damon et al,
> 
> 	A week or two ago I posted a message saying that the gtk-doc template
> Makefile has dependencies that somehow don't work when srcdir !=
> builddir. I took another look at this and figured out the problem.
> 
> 	Take for example the scanning rules:
> 
> scan-build.stamp: $(HFILE_GLOB)
>         @echo '*** Scanning header files ***'
> 	<do the scanobj>
> 	<do the scan>
>         touch scan-build.stamp
> 
> $(DOC_MODULE)-decl.txt $(SCANOBJ_FILES): scan-build.stamp
>         @true
> 
> Examine the dependencies for something in $(SCANOBJ_FILES), say
> "glib.args". Such a file depends on scan-build.stamp, which is created
> /after/ "glib.args" is created by the scanobj -- the "touch" comes after
> the gtkdoc-scanobj. Thus this dependency is never satisfied.

I'm not sure what you mean by "never satisfied" - its intentional
that scan-build.stamp is left newer than the files that depend
on it.

What this rule does is expresses:

"$(DOC_MODULE)-decl.txt $(SCANOBJ_FILES) are up to date if scan-build.stamp is up to date."
It doesn't matter that @true is run every time you type 'make'.
 
> Unfortunately the situation is not quite so simple; the other targets
> have this problem but do not have the quasi-circular dependency, and
> moving the "touch scan-build.stamp" before the scanobj did not help. And
> this doesn't seem to be a problem when srcdir = builddir.
> 
> However, I found that the following works:
> 
> $(DOC_MODULE)-decl.txt $(SCANOBJ_FILES): scan-build.stamp
>         touch $@
> 
> (And analogously for the tmpl and sgml rules) It seems kind of ugly but
> gets the job done. (Full disclosure; I haven't tested this when srcdir =
> builddir but I can't imagine how it could cause any problems.)
> 
> So: is this a reasonable change to make in the example? should I start
> sending patches to other projects?

I don't think this is the right change. I'll take a look at your other
mail and see if I can figure out the real problem.

Regards,
                                        Owen





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]