[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/4] docs: add build infrastructure for gtkdocs
Date: Thu, 15 Dec 2011 08:10:04 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

On 12/15/2011 07:43 AM, Avi Kivity wrote:
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/


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.

Man, it's just not easy anymore to start epic flame wars... I guess I'll have to go back to coding.

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.

This is definitely the best tool for the job. If we're not willing to live with underscores and upstream won't carry the patch, forking is our only option. We can do it as a git submodule though which will make life fairly easy.


Anthony Liguori

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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]