>It's not opt-in: once a recipe is using doxygen.bbclass then it has a build
>dependency on doxygen-native and *will* generate documentation.
>This is needless overhead if you don't intend to read the documentation.
I think if you intend to read the documentation. Just inherit this class. If
not. there is no need to inherit this class.
>You can't assert that the documentation is solely generated on the shipped
>files in the tarballs: what if some of the files are machine-generated? Or if
>with for example DBus, the doxygen is generated?
>I've nothing against a doxygen class and would like to also see a gtk-doc
>class that isn't a stub, with a single distribution-level "generate API
>documentation" variable controlling them. But the documentation has to be
>generated at build time, and I think it's fair to assume that is a package has
>API documentation then "make" will build it, otherwise the method to build the
>documentation will be different for every package.
>For example, DBus has a Doxyfile.in at the top of the source tree, so not only
>does configure needs to run to generate a Doxyfile but that Doxyfile is
>written to ${B}, not ${S}.
OK. You are right. What about configure task? Maybe we should adjust this task
before it. Doxyfile(or other name) is the file which will be used by doxygen.
It is one part of source code to be maintain.
Zongchun
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
