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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 19/06/2013 22:00, Michael Tokarev ha scritto:
> 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.

I think something like this would still be messy:

common-obj-y += $(p)core.o $(p)smbus.o $(p)smbus_eeprom.o
common-obj-$(CONFIG_VERSATILE_I2C) += $(p)versatile_i2c.o
common-obj-$(CONFIG_ACPI) += $(p)smbus_ich9.o
common-obj-$(CONFIG_APM) += $(p)pm_smbus.o
common-obj-$(CONFIG_BITBANG_I2C) += $(p)bitbang_i2c.o
common-obj-$(CONFIG_EXYNOS4) += $(p)exynos4210_i2c.o
obj-$(CONFIG_OMAP) += $(p)omap_i2c.o

and this is why I preferred per-target variable values to magic variable
names.

I also disliked the duplication, but in fact you do not even have the
duplication if you use libtool and make a .la convenience library
(similar to "ld -r" but preserving library dependencies) for each
module, even if it is builtin.  Then you can link the .la either into a
.so module, or add it to the executable.

If you do this, the LIBS only goes into a $(obj)/foo.la target-specific
variable.

>>>>> 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?

I was thinking of a module that optionally uses a library.  For example
raw block I/O may optionally use the linux AIO library.  But you would do

module-raw-posix-$(CONFIG_LINUX_AIO) += linux-aio.o
libs-linux-aio.o = -laio

or something like that, not

module-raw-posix-$(CONFIG_LINUX_AIO) += linux-aio.o
libs-raw-posix-$(CONFIG_LINUX_AIO) += -laio

So it looks like there's no need for the -y here, indeed.

Paolo