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

[Michael Tokarev]

01.07.2013 19:20, Paolo Bonzini wrote:
> Il 01/07/2013 17:06, Michael Tokarev ha scritto:
>> 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))
> 
> If I have to choose my poison, I prefer the directory multiple times.

Actually I too - it is just more obvious this way, and the
typing isn't _that_ numerous.

> But both seem worse than what we have now?

It is.  Because of the half-magic-half-not which I mentioned
multiple times.

Currently we don't have lots of per-object (or per-module)
variables, it is the opposite: they're rare:

  $(obj)/foo.o: CFLAGS += -DFOO

When we have more of these (in one or another form - for extra
libs, for additional #defines like that), the makefiles becomes
much less clean:

  obj-y += foo.o
  $(obj)/foo.o: CFLAGS += -DFOO

Why for obj-y you write plain foo.o, while for CFLAGS you use
$(obj)/foo.o ?

This is exactly my half-magic-half-nonworking thing I'm referring
to.  The more individual variables like this you have, the more
non-obvious it becomes - where to use $(obj) and where not to.

So at the end, I think, it is better to just use it everywhere
(and at the same time just get rid of it entirely, and just specify
directory prefix directly), than to have this mix of magic and
explicity.

>> So the difference is just the addition of the pathnames,
>> not the logic or ifdeffery.
> 
> Even after you factor in user-level vs. softmmu, tools, KVM vs. Xen vs.
> TCG, and all that?

I think yes.  I don't _yet_ know it as a whole, but so far it sounds
doable and actually quite clean.  But only if done _carefully_.

>>> 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.
> 
> When diff3 goes haywire because you're merging features back to a
> 4-year-old version, it matters a lot.

You can't merge a 4-year-old version regardless, because during
last 4 years lots of stuff has been rewritten, and some (like
the build system) even multiple times.

>> (Again, the "half" here refers to the fact that some variables
>> gets prefixed by the subdir automatically while some doesn't).
> 
> Which *-obj-y variables do not get prefixed?

For example, per-object variables like foo.cflags (or cflags-foo-y).
Actually anything except of a few "magic" variables.

It is not obvious to me why are you asking -- you know exactly what
gets prefixed and what not.

>> 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?
> 
> addprefix is bad.  Specifying paths explicitly is not bad _per se_, but
> if a directory is used to group related code, I think the Makefile
> should also be separated.  For example in the future we may have Kconfig
> files in hw/*, and of these three possibilities, (1) and (2) would be
> worse than (3):
> 
> 1) use a single huge Kconfig file for all devices, use a single
> Makefile.objs;
> 
> 2) split Kconfig, keep a single Makefile.objs file;
> 
> 3) split both the Kconfig and the Makefile.objs files.

There's nothing that stops you from using multiple makefile fragments.
Nothing at all.  What I'm saying is to get rid of the half-magic
only, and just use plain include subdir/Makefile.objs (or whatever),
nothing more nothing less.

With all targets made this way -- something like this:

targets-$(CONFIG_TARGET_I386) += i386-softmmu/qemu-system-softmmu

i386-softmmu/qemu-system-softmmu: $(i386-softmmu-obj-y)
(or ...: $(addprefix i386-softmmu/,$(i386-softmmu-obj-y)))
...

-- be it in the single main makefile or in a submake, it doesn't
really matter at all at this point! -- but just without the magic,
it becomes rather interesting and strightforward.

Thanks,

/mjt

>> (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).
> 
> I agree.  And again QEMU is doing half-this half-that, but I don't see
> any alternative.
> 
> Paolo
>