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
