01.07.2013 19:20, Paolo Bonzini wrote:
> Il 01/07/2013 17:06, Michael Tokarev ha scritto:
>> So instead of this, we may have in the top-level Makefile:
>>
>> obj-i386-y += hw/i386/msi.o hw/i386/irq.o hw/i386/kvm.o
>>
>> Or, if you prefer programmatic expansion,
>>
>> list-i386-y += msi.o irq.o
Il 01/07/2013 17:06, Michael Tokarev ha scritto:
> So instead of this, we may have in the top-level Makefile:
>
> obj-i386-y += hw/i386/msi.o hw/i386/irq.o hw/i386/kvm.o
>
> Or, if you prefer programmatic expansion,
>
> list-i386-y += msi.o irq.o kvm.o
> obj-i386-y += $(addprefix hw/i386/,
01.07.2013 18:53, Paolo Bonzini wrote:
[]
> I don't think that's the problem. Simply I don't think that listing
> 1000 object files in a single makefile are manageable. Choosing the
> right directory per-target is also much easier if you can just do
>
> obj-y += hw/$(TARGET_BASE_ARCH)/
>
Am 01.07.2013 16:43, schrieb Michael Tokarev:
> 01.07.2013 17:39, Paolo Bonzini wrote:
>> What used to be there was something like
>>
>>net-obj-y = foo.o bar.o
>>common-obj-y += $(addprefix net/, $(net-obj-y))
>>
>> and this has been replaced by net/Makefile.objs and friends.
>
> Maybe we
Il 01/07/2013 16:46, Andreas Färber ha scritto:
>> >
>> > What's wrong with a single makefile for everything, except
>> > of the need to use full pathnames from the top-level source
>> > dir?
> In short the problem we ran into was missing *.d inclusions.
> This got fixed by automatically expanding
01.07.2013 18:46, Andreas Färber wrote:
[]
>> What's wrong with a single makefile for everything, except
>> of the need to use full pathnames from the top-level source
>> dir?
>
> In short the problem we ran into was missing *.d inclusions.
> This got fixed by automatically expanding net/ to -incl
01.07.2013 17:39, Paolo Bonzini wrote:
> What used to be there was something like
>
>net-obj-y = foo.o bar.o
>common-obj-y += $(addprefix net/, $(net-obj-y))
>
> and this has been replaced by net/Makefile.objs and friends.
Maybe we should just list them all in a single makefile after all
Il 30/06/2013 17:36, Michael Tokarev ha scritto:
> 30.06.2013 19:28, Andreas Färber wrote:
>> Am 18.06.2013 19:34, schrieb Michael Tokarev:
>>> The following working patchset demonstrates a one step to plugins system:
>>> it moves various dependent libraries and stuff out from libs_softmmu or
>>> l
Il 01/07/2013 12:10, Michael Tokarev ha scritto:
>>> 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
> >>
01.07.2013 14:08, Paolo Bonzini wrote:
> Il 30/06/2013 17:23, Michael Tokarev ha scritto:
>>> 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
Il 30/06/2013 17:23, Michael Tokarev ha scritto:
>> 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 libtoo
On Sun, Jun 30, 2013 at 08:49:28PM +0400, Michael Tokarev wrote:
> 30.06.2013 19:51, Peter Maydell wrote:
> > On 30 June 2013 16:36, Michael Tokarev wrote:
> >> I don't understand. I for one like to see a plugins system used in qemu,
> >> and except of the build system everything else is easy (an
30.06.2013 19:51, Peter Maydell wrote:
> On 30 June 2013 16:36, Michael Tokarev wrote:
>> I don't understand. I for one like to see a plugins system used in qemu,
>> and except of the build system everything else is easy (and even nice,
>> there's even no need to load all plugins at startup as wa
Am 30.06.2013 17:36, schrieb Michael Tokarev:
> 30.06.2013 19:28, Andreas Färber wrote:
>> Am 18.06.2013 19:34, schrieb Michael Tokarev:
>>> The following working patchset demonstrates a one step to plugins system:
>>> it moves various dependent libraries and stuff out from libs_softmmu or
>>> libs
On 30 June 2013 16:36, Michael Tokarev wrote:
> I don't understand. I for one like to see a plugins system used in qemu,
> and except of the build system everything else is easy (and even nice,
> there's even no need to load all plugins at startup as was initially
> suggested). But for this to w
30.06.2013 19:28, Andreas Färber wrote:
> Am 18.06.2013 19:34, schrieb Michael Tokarev:
>> 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.
>
> We did hav
Am 18.06.2013 19:34, schrieb Michael Tokarev:
> 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.
We did have a more elaborate Makefile variable system befor
[Rehashing a previous thread]
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-sp
On 06/20/2013 02:49 AM, Paolo Bonzini wrote:
> This only leaves Darwin. I have no idea about that, and I don't have
> anymore a machine to test it. Andreas or Peter, can you shed light?
I have an idea that -shared works there as well.
r~
On 20 June 2013 13:39, Paolo Bonzini wrote:
> Il 20/06/2013 12:06, Peter Maydell ha scritto:
>>> > This only leaves Darwin. I have no idea about that, and I don't have
>>> > anymore a machine to test it. Andreas or Peter, can you shed light?
>> If you have something concrete you'd like me to tes
Il 20/06/2013 12:06, Peter Maydell ha scritto:
>> > This only leaves Darwin. I have no idea about that, and I don't have
>> > anymore a machine to test it. Andreas or Peter, can you shed light?
> If you have something concrete you'd like me to test I can test it.
You can modify the configure pro
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
On 20 June 2013 10:49, Paolo Bonzini wrote:
> This only leaves Darwin. I have no idea about that, and I don't have
> anymore a machine to test it. Andreas or Peter, can you shed light?
If you have something concrete you'd like me to test I can test it.
> But still, libtool wouldn't be a partic
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 i
On 06/19/2013 11:52 AM, Paolo Bonzini wrote:
>> > 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
>
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 witho
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 ob
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, corr
Il 19/06/2013 16:16, Stefan Hajnoczi ha scritto:
>> 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 blo
19.06.2013 18:16, Stefan Hajnoczi wrote:
> On Tue, Jun 18, 2013 at 09:34:00PM +0400, Michael Tokarev wrote:
>> 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 nic
On Tue, Jun 18, 2013 at 09:34:00PM +0400, Michael Tokarev wrote:
> 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
18.06.2013 21:34, Michael Tokarev wrote:
> 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, correspondin
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 c
33 matches
Mail list logo
