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. In this context, maybe it is good idea to actually get rid of both issues -- being inconsistent (the more per-object flags we add, the more inconsisten it becomes, since more and more variables requires the prefix), and make it as short as possible (so that using one-char variable name is better than 3-char). (by "user" I mean regular makefiles used in various places in the kernel, as opposed to kbuild internals). >>>> 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? >> 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). > > Because I didn't bother. :) Actually you did - you tried to clean things up a bit, but some dirt is still there. >>> common.o: $(patsubst %,../%, $(common-obj-y)) >>> $(LD) -r -o $@ $^ >>> >>> and then link common.o into the QEMU target. > > I think that would make it a bit more complex to gather all the required > libs. But it is probably not insurmountable. Yes, definitely. >>>> 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. > > Do you also count one major proprietary operating system? Unfortunately > mingw still requires magic to create shared libraries. Sure. But it's not alot really. Thanks, /mjt
