On Mon, Sep 7, 2015 at 2:11 PM, Paolo Bonzini wrote:
>
>
> On 07/09/2015 23:02, Michael Marineau wrote:
>> ping http://patchwork.ozlabs.org/patch/510065/
>
> Just back from vacation, this is queued in my next pull request
> (currently at tags/for-upstream on github.com/bonzini/qemu.git, but I
> ha
On 07/09/2015 23:02, Michael Marineau wrote:
> ping http://patchwork.ozlabs.org/patch/510065/
Just back from vacation, this is queued in my next pull request
(currently at tags/for-upstream on github.com/bonzini/qemu.git, but I
haven't finished testing it).
Paolo
On Sun, Aug 23, 2015 at 5:57 PM, Michael Marineau
wrote:
> Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
> rewrite all absolute paths to relative paths. This interacts poorly with
> QEMU's two-level build directory scheme. For example, lets say
> BUILD_DIR=$(SRC_PATH)/build
Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
rewrite all absolute paths to relative paths. This interacts poorly with
QEMU's two-level build directory scheme. For example, lets say
BUILD_DIR=$(SRC_PATH)/build so build/blockdev.d will contain:
blockdev.o: ../blockdev.c ../
On Aug 12, 2015 6:32 AM, "Paolo Bonzini" wrote:
>
>
>
> On 09/08/2015 09:02, Michael Marineau wrote:
> > Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
> > rewrite all absolute paths to relative paths. This interacts poorly with
> > QEMU's two-level build directory scheme. Fo
On 09/08/2015 09:02, Michael Marineau wrote:
> Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
> rewrite all absolute paths to relative paths. This interacts poorly with
> QEMU's two-level build directory scheme. For example, lets say
> BUILD_DIR=$(SRC_PATH)/build so build/bl
Using ccache with CCACHE_BASEDIR set to $(SRC_PATH) or a parent will
rewrite all absolute paths to relative paths. This interacts poorly with
QEMU's two-level build directory scheme. For example, lets say
BUILD_DIR=$(SRC_PATH)/build so build/blockdev.d will contain:
blockdev.o: ../blockdev.c ../
On 26/05/2015 19:15, Peter Crosthwaite wrote:
> On Tue, May 26, 2015 at 6:29 AM, Paolo Bonzini wrote:
>>
>>
>> On 26/05/2015 07:38, Peter Crosthwaite wrote:
>>> make can be invoked in the individual build dirs to build an individual
>>> target or just a single file of a target. e.g.
>>>
>>> touc
On Tue, May 26, 2015 at 6:29 AM, Paolo Bonzini wrote:
>
>
> On 26/05/2015 07:38, Peter Crosthwaite wrote:
>> make can be invoked in the individual build dirs to build an individual
>> target or just a single file of a target. e.g.
>>
>> touch translate-all.c
>> make -C microblazeel-softmmu transla
On 26/05/2015 07:38, Peter Crosthwaite wrote:
> make can be invoked in the individual build dirs to build an individual
> target or just a single file of a target. e.g.
>
> touch translate-all.c
> make -C microblazeel-softmmu translate-all.o
Out of curiosity, why not use "make subdir-microblaze
make can be invoked in the individual build dirs to build an individual
target or just a single file of a target. e.g.
touch translate-all.c
make -C microblazeel-softmmu translate-all.o
There is however a small bug when using the pixman submodule.
config-host.mak will ref BUILD_DIR for the pixman
> > > When I was inspecting the icon using the genie feature of Mac OS X's
> > > dock, the icon looked very sharp at full size, so I didn't see a
> > > problem with it. What size do you have in mind?
> >
> > I was thinking of 16x16, 32x32, 48x48 and 128x128.
>
> What advantages do you think this
On Feb 20, 2015, at 12:56 PM, Paolo Bonzini wrote:
>
>
> On 20/02/2015 18:32, Programmingkid wrote:
>>> Ok, so I'll apply v3 to my tree as soon as I get a Tested-by.
>>> Please take a look into providing a .rsrc file with larger-sized
>>> icons (I think you can add more than one to a single .rs
On 20/02/2015 18:32, Programmingkid wrote:
>> Ok, so I'll apply v3 to my tree as soon as I get a Tested-by.
>> Please take a look into providing a .rsrc file with larger-sized
>> icons (I think you can add more than one to a single .rsrc file?)
>> and, when you do that, document in pc-bios/README
On Feb 20, 2015, at 12:05 PM, Paolo Bonzini wrote:
>
>
> On 20/02/2015 17:54, Programmingkid wrote:
>>> I suspect the Windows icon is not a great match for Mac OS X which likes
>>> to have big sizes (48x48 or 128x128).
>>
>> Definitely true.
>>
>>> If you want to generate the .rsrc
>>> file a
On 20/02/2015 17:54, Programmingkid wrote:
>> I suspect the Windows icon is not a great match for Mac OS X which likes
>> to have big sizes (48x48 or 128x128).
>
> Definitely true.
>
>> If you want to generate the .rsrc
>> file automatically, the right source probably would be the .svg file,
>
On Feb 20, 2015, at 7:36 AM, Paolo Bonzini wrote:
>
>
> On 20/02/2015 13:18, Peter Maydell wrote:
>> Why not just use the sips --out option to specify a different
>> output file? That way we automatically put the current icon
>> into the executable, and don't have to update a hand-created
>> qe
On 20/02/2015 13:36, Paolo Bonzini wrote:
>
>
> On 20/02/2015 13:18, Peter Maydell wrote:
>> Why not just use the sips --out option to specify a different
>> output file? That way we automatically put the current icon
>> into the executable, and don't have to update a hand-created
>> qemu.rsrc fi
On 20/02/2015 13:18, Peter Maydell wrote:
> Why not just use the sips --out option to specify a different
> output file? That way we automatically put the current icon
> into the executable, and don't have to update a hand-created
> qemu.rsrc file in git if we change the icon in future (and I
> b
On 19 February 2015 at 18:56, Paolo Bonzini wrote:
>
>
> On 18/02/2015 22:09, Programmingkid wrote:
>> + # Take an image and make the image its own icon:
>> + sips -i ../pc-bios/qemu-nsis.ico
>> + # Extract the icon to its own resource file:
>> + DeRez -only icns ../pc-bios/qemu-ns
On Feb 19, 2015, at 4:56 AM, Paolo Bonzini wrote:
>
>
> On 18/02/2015 22:09, Programmingkid wrote:
>> +# Take an image and make the image its own icon:
>> +sips -i ../pc-bios/qemu-nsis.ico
>> +# Extract the icon to its own resource file:
>> +DeRez -only icns ../pc-bios/qemu-nsis
On 18/02/2015 22:09, Programmingkid wrote:
> + # Take an image and make the image its own icon:
> + sips -i ../pc-bios/qemu-nsis.ico
> + # Extract the icon to its own resource file:
> + DeRez -only icns ../pc-bios/qemu-nsis.ico > tmpicns.rsrc
IIUC sips modifies ../pc-bios/qemu-ns
This patch adds the instruction to have the build commands give QEMU an icon.
This code runs on Mac OS X.
Signed-off-by: John Arbuckle
---
Makefile.target | 21 -
1 files changed, 20 insertions(+), 1 deletions(-)
mode change 100644 => 100755 Makefile.target
diff --git
On Thu, 05/08 15:02, Michael Tokarev wrote:
> $(INSTALL_PROG) is evaluated to libtool if using libtool, while
> $(INSTALL) is not. Use $(INSTALL_PROG) so that libtool is used
> with target too when necessary. This allows, for example, to
> link qemu with shared libcacard.
>
> Signed-off-by: Mich
$(INSTALL_PROG) is evaluated to libtool if using libtool, while
$(INSTALL) is not. Use $(INSTALL_PROG) so that libtool is used
with target too when necessary. This allows, for example, to
link qemu with shared libcacard.
Signed-off-by: Michael Tokarev
Cc: Fam Zheng
Cc: Paolo Bonzini
Cc: Alon
On 06/20/2012 12:02 PM, Peter Maydell wrote:
Now we create object files in a hierarchy under hw/, so the
'clean' target must also be updated to delete those object files.
Rather than using a manual list of subdirectories which will
easily drift out of date, we just delete all .o and .d files
in t
This is v2, obviously -- I forgot to change the [PATCH] prefix :-(
-- PMM
On 20 June 2012 18:02, Peter Maydell wrote:
> Now we create object files in a hierarchy under hw/, so the
> 'clean' target must also be updated to delete those object files.
> Rather than using a manual list of subdirector
Now we create object files in a hierarchy under hw/, so the
'clean' target must also be updated to delete those object files.
Rather than using a manual list of subdirectories which will
easily drift out of date, we just delete all .o and .d files
in the target directory hierarchy.
Signed-off-by:
Am 20.06.2012 15:54, schrieb Peter Maydell:
> Now we create object files in a hierarchy under hw/, so the
> 'clean' target must also updated to delete those object files.
"be updated"
Other than that and the -f looks good. Thanks.
/-F
> Rather than using a manual list of subdirectories which wi
On 20 June 2012 14:54, Peter Maydell wrote:
> Now we create object files in a hierarchy under hw/, so the
> 'clean' target must also updated to delete those object files.
> Rather than using a manual list of subdirectories which will
> easily drift out of date, we just delete all .o and .d files
>
Now we create object files in a hierarchy under hw/, so the
'clean' target must also updated to delete those object files.
Rather than using a manual list of subdirectories which will
easily drift out of date, we just delete all .o and .d files
in the target directory hierarchy.
Signed-off-by: Pet
On Sun, Mar 18, 2012 at 08:47:15AM +0100, Alon Levy wrote:
> Signed-off-by: Alon Levy
> ---
> Makefile.target |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Nice catch, thanks!
Applied to the tracing patches tree:
https://github.com/stefanha/qemu/commits/tracing
Stefan
Signed-off-by: Alon Levy
---
Makefile.target |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.target b/Makefile.target
index eb25941..5c62edb 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -58,7 +58,7 @@ else
TARGET_TYPE=system
endif
-$(QEMU_PROG).stp:
+$
Remove some dependency rules which aren't necessary (the automatically
generated .d files cover all these). These were leftovers from dyngen
days, when the object files also had a dependency on some generated
files.
Signed-off-by: Peter Maydell
---
Makefile.target |6 --
1 files changed,
> But nevertheless, sometimes it happens that I "do that",
> and then I'm always happy when I get a clear error
> message. Or even better, when something works as
> expected even when I did something unexpected.
> You are lucky if you never experienced such situations.
>
> In my case, even a simple
Hi Paul,
of course it is always good practice to avoid errors.
But nevertheless, sometimes it happens that I "do that",
and then I'm always happy when I get a clear error
message. Or even better, when something works as
expected even when I did something unexpected.
You are lucky if you never exp
On Sunday 15 April 2007 14:57, Stefan Weil wrote:
> This small patch for Makefile.target fixes a very special build issue:
>
> make distclean # (only needed to remove files left from earlier builds)
> ./configure
> make -C i386-softmmu # (or any other system emulation)
>
> will try to build the mis
This small patch for Makefile.target fixes a very special build issue:
make distclean # (only needed to remove files left from earlier builds)
./configure
make -C i386-softmmu # (or any other system emulation)
will try to build the missing dyngen and fail because dyngen is
normally build by the r
This patch cleans up Makefile target for sparc32 and sparc64
Solaris and non-Solaris targets share a large amount of the
definitions, so I split out the common parts and isolate just
the Solaris/non-Solaris portions and added readability.
Also fixed the x86_64 targets for Solaris to not use the
39 matches
Mail list logo
