On Freitag, 11. September 2020 19:19:05 CEST Paolo Bonzini wrote:
> On 10/09/20 16:40, Christian Schoenebeck wrote:
> > If it turns out to work fine, then maybe I just push a branch of QEMU for
> > Mac developers somewhere for a while, as I think it would lower the entry
> > level for new developer
On 10/09/20 16:40, Christian Schoenebeck wrote:
> If it turns out to work fine, then maybe I just push a branch of QEMU for Mac
> developers somewhere for a while, as I think it would lower the entry level
> for new developers on Mac tremendously. Apparently there is still more
> changes
> with
On Donnerstag, 10. September 2020 12:35:46 CEST Peter Maydell wrote:
> Does Apple (or anybody else) provide a framework for doing this
> so that developers of individual applications can just say "my
> app needs libs X, Y, Z" and they don't have to mess around
> finding, figuring out how to compile
> On 10 Sep 2020, at 13:45, Daniel P. Berrangé wrote:
>
> AFAICT both MacPorts and HomeBrew can be installed into custom locations,
> at least if you do a "from source" install of them, rather than using the
> pre-built packages.
Yes, I use this for HomeBrew, but generally you cannot select t
On Thu, Sep 10, 2020 at 12:41:45PM +0200, Paolo Bonzini wrote:
> Il gio 10 set 2020, 11:32 Christian Schoenebeck ha
> scritto:
>
> > On Donnerstag, 10. September 2020 09:37:10 CEST Daniel P. Berrangé wrote:
> > > I don't think we want to be adding more 3rd party deps as submodules,
> > quite
> >
On Thu, Sep 10, 2020 at 11:35:46AM +0100, Peter Maydell wrote:
> On Thu, 10 Sep 2020 at 11:14, Christian Schoenebeck
> wrote:
> > For developers it is actually the complete opposite on Mac: you start to
> > install things from somewhere, then you need to install something from
> > somewhere else,
Il gio 10 set 2020, 11:32 Christian Schoenebeck ha
scritto:
> On Donnerstag, 10. September 2020 09:37:10 CEST Daniel P. Berrangé wrote:
> > I don't think we want to be adding more 3rd party deps as submodules,
> quite
> > the opposite, we want to remove more submodules we currently have.
> >
> >
On Thu, 10 Sep 2020 at 11:14, Christian Schoenebeck
wrote:
> For developers it is actually the complete opposite on Mac: you start to
> install things from somewhere, then you need to install something from
> somewhere else, manually build & install stuff, and you end up in conflicts
> and misbeha
> On 10 Sep 2020, at 13:14, Christian Schoenebeck
> wrote:
>
> The way to go for devs on Mac is: 3rd party libs should not be installed into
> global space, rather be built & linked either as dynamic frameworks
> (including
> assets) or as static libs. Then apps always run with the precise
> On 10 Sep 2020, at 12:20, Paolo Bonzini wrote:
>
> --python=/path/to/python3 --meson=internal
>
> and the build will automatically use that same Python executable to run
> the scripts.
Ok, good to know.
My standalone meson is intended for integration into Eclipse and Visual Studio
Code,
On Donnerstag, 10. September 2020 11:39:10 CEST Daniel P. Berrangé wrote:
> > Well, that's actually the whole point of this thread: saving developers'
> > time. And I think the submodule solution is the most sane one.
> >
> > Frankly if you compile FOSS software on Mac that asks you to "just"
> >
On Thu, Sep 10, 2020 at 11:32:35AM +0200, Christian Schoenebeck wrote:
> On Donnerstag, 10. September 2020 09:37:10 CEST Daniel P. Berrangé wrote:
> > I don't think we want to be adding more 3rd party deps as submodules, quite
> > the opposite, we want to remove more submodules we currently have.
>
On Donnerstag, 10. September 2020 09:37:10 CEST Daniel P. Berrangé wrote:
> I don't think we want to be adding more 3rd party deps as submodules, quite
> the opposite, we want to remove more submodules we currently have.
>
> Bundling every important dep we use as a submodule and providing build
>
On 09/09/20 22:13, Liviu Ionescu wrote:
>> ... You still need a Python 3.5 or better for the other scripts
>> QEMU has as part of its build process, so you will still need a
>> python other than the Apple /usr/bin/python to build even if you
>> have a standalone meson with its own python.
>
> Ah,
On Wed, Sep 09, 2020 at 08:56:48PM +0200, Christian Schoenebeck wrote:
> On Mittwoch, 9. September 2020 20:13:55 CEST Daniel P. Berrangé wrote:
> > > On Mittwoch, 9. September 2020 15:40:05 CEST Daniel P. Berrangé wrote:
> > > > Ideally any xcode setup would just invoke whatever our standard
> > >
> On 9 Sep 2020, at 22:16, Peter Maydell wrote:
>
> ... You still need a Python 3.5 or better for the other scripts
> QEMU has as part of its build process, so you will still
> need a python other than the Apple /usr/bin/python to build
> even if you have a standalone meson with its own python
On Mittwoch, 9. September 2020 21:03:32 CEST Liviu Ionescu wrote:
> > On 9 Sep 2020, at 21:56, Christian Schoenebeck
> > wrote:
> >
> > ... However you would
> > still be opted out from (4.) all those Xcode IDE features that make
> > development such efficient.
>
> Could you elaborate?
>
> I th
On Wed, 9 Sep 2020 at 19:56, Christian Schoenebeck
wrote:
> Interesting! That would defuse the homebrew problematic.
You still need a Python 3.5 or better for the other scripts
QEMU has as part of its build process, so you will still
need a python other than the Apple /usr/bin/python to build
eve
> On 9 Sep 2020, at 21:56, Christian Schoenebeck wrote:
>
> ... However you would
> still be opted out from (4.) all those Xcode IDE features that make
> development such efficient.
Could you elaborate?
I thought that a standalone meson can be used with any environment, it just
reduces th
On Mittwoch, 9. September 2020 20:13:55 CEST Daniel P. Berrangé wrote:
> > On Mittwoch, 9. September 2020 15:40:05 CEST Daniel P. Berrangé wrote:
> > > Ideally any xcode setup would just invoke whatever our standard
> > > build tools are IMHO, so it has zero possibility of introducing
> > > new bui
> On Mittwoch, 9. September 2020 15:40:05 CEST Daniel P. Berrangé wrote:
> > Ideally any xcode setup would just invoke whatever our standard
> > build tools are IMHO, so it has zero possibility of introducing
> > new build problems.
>
> Then you would not win anything on Mac. The problematic on ma
> On 9 Sep 2020, at 20:32, Christian Schoenebeck wrote:
>
> And being forced to use Meson
> on Mac with all its Python dependencies does not make it easier.
FYI, I'm working on a cross-platform standalone meson package, a .tar.gz that
you can install in any location and includes the python
On Mittwoch, 9. September 2020 15:30:09 CEST Peter Maydell wrote:
> On Wed, 9 Sep 2020 at 13:56, Christian Schoenebeck
>
> wrote:
> > I've recently been thinking about how feasible a stripped down Xcode
> > project for QEMU would be, i.e. you just get the QEMU sources, click on
> > qemu.xcodeproj
On 09/09/20 15:41, Thomas Huth wrote:
>> The question is, and I don't have the big picture of QEMU yet to judge that,
>> how much is auto generated for QEMU i.e. with custom scripts that would
>> probably destroy this plan? There are these trace calls that are auto
>> generated, is there more li
> On Sep 9, 2020, at 8:56 AM, Christian Schoenebeck
> wrote:
>
> I've recently been thinking about how feasible a stripped down Xcode project
> for QEMU would be, i.e. you just get the QEMU sources, click on
> qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing.
>
>
On Wed, Sep 09, 2020 at 03:41:02PM +0200, Thomas Huth wrote:
> On 09/09/2020 14.56, Christian Schoenebeck wrote:
> > I've recently been thinking about how feasible a stripped down Xcode
> > project
> > for QEMU would be, i.e. you just get the QEMU sources, click on
> > qemu.xcodeproj, Cmd + B, d
> On 9 Sep 2020, at 16:30, Peter Maydell wrote:
>
> My experience with homebrew has been pretty good overall.
Homebrew is fine for use cases that don't mind it is a rolling distribution. :-(
For complex builds it is safer to lock the environment to certain known to work
versions, and homebr
On 09/09/2020 14.56, Christian Schoenebeck wrote:
> I've recently been thinking about how feasible a stripped down Xcode project
> for QEMU would be, i.e. you just get the QEMU sources, click on
> qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing.
Meson seems to have so
On Wed, Sep 09, 2020 at 02:56:46PM +0200, Christian Schoenebeck wrote:
> I've recently been thinking about how feasible a stripped down Xcode project
> for QEMU would be, i.e. you just get the QEMU sources, click on
> qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing.
>
On Wed, 9 Sep 2020 at 13:56, Christian Schoenebeck
wrote:
> I've recently been thinking about how feasible a stripped down Xcode project
> for QEMU would be, i.e. you just get the QEMU sources, click on
> qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing.
How would this
I've recently been thinking about how feasible a stripped down Xcode project
for QEMU would be, i.e. you just get the QEMU sources, click on
qemu.xcodeproj, Cmd + B, done. No extra installation, no configure, nothing.
I've done this before for gtk(mm), which you might know, depends on approx. 24
31 matches
Mail list logo
