Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries

[Michael Tokarev]

01.07.2013 18:53, Paolo Bonzini wrote:
[]
> I don't think that's the problem.  Simply I don't think that listing
> 1000 object files in a single makefile are manageable.  Choosing the
> right directory per-target is also much easier if you can just do
> 
>       obj-y += hw/$(TARGET_BASE_ARCH)/
> 
> instead of long if-elseif-elseif-elseif-endif conditionals.

it's not this.  It is something like:

 obj-$(TARGET_BASE_ARCH) += $($(target)-base-arch)

instead, where $(target)-base-arch still has to be defined
very much the same like it is defined today, with the exception
that it doesn't require to be listed in a separate Makefile.

Ie, today, we have, say, in hw/i386/Makefile.objs:
   obj-y += msi.o irq.o kvm.o
   obj-y += msi2.o kvm2.o

So instead of this, we may have in the top-level Makefile:

  obj-i386-y += hw/i386/msi.o hw/i386/irq.o hw/i386/kvm.o

Or, if you prefer programmatic expansion,

  list-i386-y += msi.o irq.o kvm.o
  obj-i386-y += $(addprefix hw/i386/, $(list-i386-y))

So the difference is just the addition of the pathnames,
not the logic or ifdeffery.

> Conflicts in a small file are also way easier to solve, even if there
> are more conflicting files.

Conflicts?  Which conflicts?  You mean merge conflicts?
If yes, it does not really matter be it small file or large
file.  If you list everything in one line, you're much more
likely to have a conflict, be it small file or large file.
If you always add stuff to the end of a file, you have much
more chance for a conflict, be it large or small file.
Single makefile may have sections so, say, you add a new
block device into a "block" section, maybe near the end of
it or alphabetically, so you're avioding conflicts the
same way as if you had multiple files.

> If you prefer to have _everything_ in a single file, you just have to
> post patches and justify them.  I just doubt that the result will be
> better than what we have today, and the time would be better invested in
> cleaning up what we have today.

Well, the more I look into it, the more I dislike what we have
now, because of this non-obvious half-magic half-working stuff.
To me we should either do it recursively in submakes, or just
add the paths (be it single makefile or multiple small makefiles)
without the current half-working half-magic.

(Again, the "half" here refers to the fact that some variables
gets prefixed by the subdir automatically while some doesn't).

So before sending patches, can we at least agree (or not) that
specifying paths explicitly (either using dir/obj.o or by calling
addprefix) is not THAT bad or it should be avoided entirely?

(I dislike the recursive sub-make approach because when you have
everything in one make it is much easier to see all dependencies
and plan the work, instead of running a ton of submakes first,
each checking if its own subdir is up to date).

Thanks,

/mjt