Re: [Qemu-devel] [PATCH 00/24] per-directory Makefile snippets, limit vpath abuse

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/04/2012 06:40 AM, Andreas Färber wrote:
> Am 03.06.2012 14:25, schrieb Paolo Bonzini:
>> One source of complexity in the QEMU source is that we have a very
>> shallow tree for a source code of over 750,000 lines of code.  In
>> fact, one third of these lines alone is in one directory, hw/.
>>
>> As a prerequisite to cleaning up the structure, but as a worthwhile
>> step on its own, this patchset cleans up the build system so that
>> separate directories have their own Makefile snippet.  As in the Linux
>> kernel build system, the overall build system is generally flat (in
>> the case of QEMU, with one recursive invocation per emulation target).
>> Subdirectories do not include complete Makefiles, instead they only host
>> the declarations for a few variables (common-obj-y, universal-obj-y,
>> obj-y, etc.).  Definitions for all the directories are merged with a
>> little GNU Make magic (not much, only 20 lines).
>>
>> Two nice side effects are:
>>
>> - we can match the source tree and the object tree (for example the
>>    per-target device models will be in XYZ-softmmu/hw, not in
>>    XYZ-softmmu; those that are compiled once will be in hw/ rather
>>    than in the root).
>>
>> - because the resolution of nested makefiles tracks the nested
>>    directory, there is no need to use VPATH to find sources in
>>    the hw/ and target-*/ directory.
>>
>> - there is a lot less Makefile programming (conditionals, addprefix,
>>    etc.), replaced by only 20 lines in rules.mak and 1 in Makefile.objs.
>>
>> The series is entirely bisectable, and mostly consists of boring patches.
>> If the concept is accepted, I would like to get it in as soon as possible.
>> I have a few other cleanups on top (I stopped once I undid the diffstat
>> of this series :)), but they can be covered later.
>>
>> Thoughts, approvals, rejections?
>
> As before, I dislike the use of the filename "Makefile" for files that
> are not self-contained. If make is called from that deep directory, it
> leads to undefined results. Either we must make sure through some clever
> ifeq'ery and a local "all" target that such an attempt fails, or better
> use a filename that is recognized by editors as Makefile syntax but not
> used by make without explicit -f, e.g., foo.mak.

Linux does this.  I think it's expected behavior at this point.  In the long 
term, we should either move to kconfig or autoconf so trying to act like one of 
the two seems like a good idea to me.

> Note that I have been working on moving some more files from
> Makefile.target to Makefile.objs for compilation into libhw{32,64}. I'll
> defer that if people agree this is the way to restructure.
>
> Anthony had been talking about restructuring hw/ into a more Linux-like
> directory structure. Any update on that, Anthony?

Yes, I had a similar (but uglier) patch to this that was a pre-req.  This 
approach is much better though.  I'd like to get this applied ASAP so we can 
start shuffling things around.

BTW, we should change the build rules in rules.mak too such that they create 
output directories on demand.  Then we can add new subdirectories without 
touching configure which is a bit annoyance right now.

Regards,

Anthony Liguori

>
> Regards,
> Andreas
>