qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Tokarev
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries
Date: Wed, 19 Jun 2013 22:18:42 +0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Icedove/17.0

19.06.2013 20:58, Paolo Bonzini wrote:
> 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).

/me dislikes duplication :)

[]
> 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.

I'm not really changing meaning of $(obj), it is still a subdir, but
it might be empty (for a top-level dir) too, which is different from
current-dir  (.).

Initially your $(obj) starts with `.', and expands with slashes at the
end.  So a object-specific variables -- like


 $(obj)/foo.cflags = -DFOOBAR

are - after expansion - named like  `./foo.cflags'.  Nothing is wrong
with that.

The only prob here is that when you expand lists of objects/modules to
process, it includes foo.o bar.mod, not ./foo.o ./bar.mod.

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).

It really is a directory prefix (hence I prefer $(p) -- it is short
and can be referred to as either path or prefix), it is not a directory
with object files.  When you think about it this way, it becomes
much cleaner.

Also, it should be possible to add a test that all $(obj)- (or $(p)-)
prefixed paths don't include the slash, so in case of any mistakes
happens they will be detected early.

And since it looks like this mechanism is useful enough to be
used widely, I think the shorter the name, the better.

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

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).

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

I already changed that part a bit, by adding a second argument
to the $(LINK) rule, but I don't think it is less ugly.

> common.o: $(patsubst %,../%, $(common-obj-y))
>       $(LD) -r -o $@ $^
> 
> and then link common.o into the QEMU target.

Well, that might not be a bad idea.  I'll think about it.

That might actually be turned into a shared library (or two
or even 3 -- for tools, for softmmu targets and for user
emulation).

>        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.  We're basically stick with gcc and so with whole
toolchain (and with gnu make having in mind all the above tricks!),
even windows programs are build with mingw only.  In this restricted
environment it is easy to go stright into gcc command line instead of
using a wrapper which adds its own complexity.  And even if that is
not sufficient, we can just skip playing all these plugin/shared
games on "unsupported" systems.

I already looked at the gmodule wrapper around dlopen()/LoadLibrary() --
there's no need even in that wrapper, stright OS interface looks more
accurate.

(Speaking of running qemu from the build dir -- I think we'll need an
option, like -plugin-dir, to be able to speclfy plugins just built).

>> 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! :)

Well, time will tell ;)
But I don't actually see a reason for that, -- if the mechanism will
be easy and works, there's no problem in using it.

Thanks!

/mjt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]