From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpboC-0002kr-Gp for qemu-devel@nongnu.org; Thu, 20 Jun 2013 06:09:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Upbo7-0006Ez-JI for qemu-devel@nongnu.org; Thu, 20 Jun 2013 06:09:40 -0400 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:41294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Upbo7-0006Ed-AG for qemu-devel@nongnu.org; Thu, 20 Jun 2013 06:09:35 -0400 Received: by mail-ea0-f177.google.com with SMTP id j14so3837765eak.22 for ; Thu, 20 Jun 2013 03:09:34 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51C2D4D7.2000608@redhat.com> Date: Thu, 20 Jun 2013 12:09:27 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1371576844-28743-1-git-send-email-mjt@msgid.tls.msk.ru> <51C1E335.9010304@redhat.com> <51C1F602.4040806@msgid.tls.msk.ru> <51C1FDF8.5030104@redhat.com> <51C20DCE.6080502@msgid.tls.msk.ru> In-Reply-To: <51C20DCE.6080502@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: qemu-devel@nongnu.org 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