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