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

[Michael Tokarev <mjt@tls.msk.ru>]

19.06.2013 22:52, Paolo Bonzini wrote:
> Il 19/06/2013 20:18, Michael Tokarev ha scritto:
>> Currently I expand it like this:
>>
>>   $(foreach m, $(filter %.o,$1), $($(m:%.o=%.libs)))
>>
>> Probably I can change that to
>>
>>   $(foreach m, $(filter %.o,$1), $($(m:%.o=./%.libs)))
>>
>> (here and in other similar cases), and it will work without changing
>> anything around $(obj).
>>
>> But maybe we can argee here that this is not really OBJect, it is
>> a path or dir, and name it $(d) or $(p) instead of $(obj) ?  To
>> include the slash when needed. just like I did for $(obj).
> 
> I chose $(obj) because that's what Kbuild uses.

kbuild almost never requires this variable in "user" makefiles
(not counting kbuild internals), -- because of recursive way
of its working there's no need to prepend directory names like
qemu makefiles currently do, "user" makefiles refer to files
using bare (no path) names.

Contrary to that, qemu does not recurse, it tries to do everything
in one instance, so it can expand just a few "magic" variables,
and for everything else we have to explicitly use that prefix.
So that it becomes inconsistent (some vars require prefix, some
don't), and too verbose.

In this context, maybe it is good idea to actually get rid of
both issues -- being inconsistent (the more per-object flags
we add, the more inconsisten it becomes, since more and more
variables requires the prefix), and make it as short as possible
(so that using one-char variable name is better than 3-char).

(by "user" I mean regular makefiles used in various places in
the kernel, as opposed to kbuild internals).

>>>> Also, for the inevitable bikeshedding, I would prefer
>>>>
>>>>    cflags-$(obj)/curl.o-y
>>>>    libs-$(obj)/curl.o-y
>> What are all these -y suffixes for?  In existing variables and in
>> this new your invention?  It's already a bit too verbose.
> 
> It is so that you can do
> 
> foo-$(CONFIG_XYZ) += blah
> 
> instead of
> 
> ifeq ($(CONFIG_XYZ),y)
> FOO += blah
> endif

Yes, that sure I undertand -- obj-y, block-m etc.  I'm asking
about those new vars yuo propose -- why you want -y sufffix
*there*, like cflags-foo.o-y ?

Do you want to be able to specify different flags for -y and -m
builds?  Isn't it a bit too much?

>> BTW, can you take a look why your expand-nesting does not remove
>> the save- variables properly?  Run make with -p and see which
>> vars are defined.  (This is really BTW, you just reminded me
>> about something I've seen but had no chance to look at).
> 
> Because I didn't bother. :)

Actually you did - you tried to clean things up a bit, but some
dirt is still there.

>>> common.o: $(patsubst %,../%, $(common-obj-y))
>>> 	$(LD) -r -o $@ $^
>>>
>>> and then link common.o into the QEMU target.
> 
> I think that would make it a bit more complex to gather all the required
> libs.  But it is probably not insurmountable.

Yes, definitely.

>>>>        Libtool can also be used
>>>> to abstract "ld -r".  Making libtool mandatory wouldn't be a problem IMO
>>>> (we'd need it anyway for modules) as long as you do not need libtool to
>>>> start QEMU or gdb from the build directory.
>> Do we really need it for modules?  I'm not sure.  Actually, in a modern
>> world, I'm not really sure libtool is needed if you only count "major"
>> operating systems.
> 
> Do you also count one major proprietary operating system?  Unfortunately
> mingw still requires magic to create shared libraries.

Sure.  But it's not alot really.

Thanks,

/mjt