Re: [Qemu-devel] [PATCH 2/4] docs: add build infrastructure for gtkdocs

[Avi Kivity]

On 12/15/2011 03:30 PM, Anthony Liguori wrote:
> On 12/15/2011 03:37 AM, Avi Kivity wrote:
>> On 12/14/2011 06:20 PM, Anthony Liguori wrote:
>>> By convention, documented headers now go in include/
>>
>> Dislike.
>
> I've been planning on doing this for a while.  I think it's a useful
> way to help improve internal modularity.  It provides a consistent way
> to indicate which headers represent "public" internal interfaces (like
> the memory API) verses things that are really private headers specific
> to a submodule (say block_int.h).

If a submodule needs an internal header, it probably wants its own subdir.

>
> We have a real problem internally with headers too.  It's almost
> surprising how many lack guards, don't have proper #includes, etc.  By
> moving all public headers to include/, it gives us a systematic way to
> go through, clean up various headers, and have an idea of how much
> work is left to be done.

Still dislike.  But it's just dislike, not an opening shot into an
extended discussion that will expand into coding style, proposals for
changing the programming language, merging qemu into a subdirectory of
another project, etc, as much fun as it promises to be.  Do it if you
must, I'll live with it somehow.

>> Documentation should be built by default, so that errors in the format
>> are detected (and break the build).
>
> I agree, but since we now are dealing with a fork of a common tool, I
> didn't want to add a hard build dependency until I can get some
> feedback on whether upstream is willing to consider our patch.

Let's avoid a fork, either get it merged or find some other tool.

>> Does this thing not support incremental builds?
>
> As best as I can tell, no.  Every other tool I've looked as suffers
> from the same problem.

Yeah, it's equivalent to a compiler doing most of its work during the
link phase (=idea for patch).

-- 
error compiling committee.c: too many arguments to function