From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpLiQ-0003Vy-SJ for qemu-devel@nongnu.org; Wed, 19 Jun 2013 12:58:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UpLiP-0005az-Dr for qemu-devel@nongnu.org; Wed, 19 Jun 2013 12:58:38 -0400 Received: from mail-we0-x234.google.com ([2a00:1450:400c:c03::234]:65162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UpLiP-0005at-4Y for qemu-devel@nongnu.org; Wed, 19 Jun 2013 12:58:37 -0400 Received: by mail-we0-f180.google.com with SMTP id w56so4721894wes.11 for ; Wed, 19 Jun 2013 09:58:36 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <51C1E335.9010304@redhat.com> Date: Wed, 19 Jun 2013 18:58:29 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1371576844-28743-1-git-send-email-mjt@msgid.tls.msk.ru> In-Reply-To: <1371576844-28743-1-git-send-email-mjt@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 18/06/2013 19:34, Michael Tokarev ha scritto: > The following working patchset demonstrates a one step to plugins system: > it moves various dependent libraries and stuff out from libs_softmmu or > libs_tools to object-specific variables. When that object is linked > into final executable, corresponding libs are expanded and appended to > the linking command line. > > I took block/curl.o as an example (in the last patch). > > This is a working example which can be used as is as a starting point > to convert other similar cases. I was thinking of this problem too while drafting the modules feature page. My solution had some duplication: libs-$(CONFIG_CURL) += $(CURL_LIBS) $(obj)/curl.so: libs-$(CONFIG_CURL) += $(CURL_LIBS) where the .so rule would use $(libs-y) $(libs-m). > There are a few questions still. > > I'm not sure whenever this $(obj)foo.o syntax (instead of $(obj)/foo.o) > is okay, using the slash is more natural, but when you realize that > objects can be stored in current dir it may be okay. However, it is > easy to make mistakes here in new code -- probably trivially catchable. > > The foo.cflags isn't really necessary, but when you specify one > thing one way (target-specific variable), and another thing completely > different way, resulting code does not look nice. In particular, the > two curl definitions in block/Makefile.objs look somewhat funky if > curl.cflags isn't used. I like this solution, and I agree that consistency between cflags and libs is good. However, it would be great if you could do it without changing the meaning of $(obj). It is not clear to me (from reading the patches) why you need that. Also, for the inevitable bikeshedding, I would prefer cflags-$(obj)/curl.o-y libs-$(obj)/curl.o-y > It is quite a bit ugly to strip out ../ in the link line, but it is > also ugly to add that ../ in the first place. Maybe I should add a > comment in Makefile.target where it adds ../ to also refer to > rules.mak, and back, for clarity. The ../ is ugly indeed. Perhaps we can instead use something like common.o: $(patsubst %,../%, $(common-obj-y)) $(LD) -r -o $@ $^ and then link common.o into the QEMU target. 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. > In configure, we may define $(obj)curl.libs directly, but for that > to work we should know where exactly the curl.o is located. > > At the same time, we may just as well use basenames (without paths) > to define per-object variables -- this way we wont need to strip > ./ from $(obj) or any other black magic, but we should ensure that > all basenames are unique, or else bad things may happen. This would be worse than the disease, I think. > When you build a library from an object, its libs aren't propagated. > It is fixable, by creating library.libs variables and expanding them > at executable link time, but since not all objects from the lib may > be necessary, this isn't nice. > > Generally, is is expected that obj.libs variables will be used only > for common optional objects like "plugins". Not necessarily! :) Paolo > Michael Tokarev (4): > build-sys: strip leading ./ from $(obj) > build-sys: allow object-specific libraries to be used to link executables > build-sys: allow per-object foo.cflags variables > build-sys: move -lcurl out of libs and specify it for curl.o > > audio/Makefile.objs | 4 ++-- > backends/Makefile.objs | 2 +- > block/Makefile.objs | 4 ++-- > configure | 3 +-- > hw/audio/Makefile.objs | 2 +- > rules.mak | 16 ++++++++++------ > trace/Makefile.objs | 26 +++++++++++++------------- > ui/Makefile.objs | 6 +++--- > 8 files changed, 33 insertions(+), 30 deletions(-) >