Message ID | 1596741379-12902-1-git-send-email-pbonzini@redhat.com |
---|---|
Headers | show |
Series | Meson integration for 5.2 | expand |
On Thu, 6 Aug 2020 21:13:56 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > This the more or less final version of the Meson conversion. Due to > the sheer size of the series you have been CCed only on the cover > letter. > > The series reaches the point where Makefile.target and unnest-vars > can be removed, and all builds become non-recursive. I have also > converted parts of the testsuite, notably qtest since it is needed > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > 2) moving the rest of installation to meson (for which I have patches); > 3) moving feature detection from configure to meson. > > Things I still haven't tested: > - fuzzing > - non-x86/Linux builds So, I was planning to give it a go on s390, but I cannot even build it on x86 (fails configure): Build started at 2020-08-07T08:43:43.873638 Main binary: /usr/bin/python3 Build Options: -Doptimization=2 -Ddebug=true -Dwerror=true -Dstrip=true -Db_pie=true -Db_coverage=false -Dsdl=auto -Dsdl_image=auto -Dvnc=enabled -Dvnc_sasl=auto -Dvnc_jpeg=auto -Dvnc_png=auto -Dprefix=/usr/local -Dbindir=/usr/local/bin -Ddatadir=/usr/local/share -Dincludedir=/usr/local/include -Dlibdir=/usr/local/lib -Dlibexecdir=/usr/local/libexec -Dlocalstatedir=/usr/local/var -Dmandir=/usr/local/share/man -Dsysconfdir=/usr/local/etc Python system: Linux The Meson build system Version: 0.52.0 Source dir: /home/cohuck/git/qemu Build dir: /home/cohuck/git/qemu/build Build type: native build meson.build:438:22: ERROR: Key must be a string. config_target_h += {target: configure_file(output: target + '-config-target.h', ^ (Fedora 31, version from your github branch) Is there anything special I need to install beyond meson? > - static builds > - Docker and VM builds > > Things I have checked: > - x86 builds > - modules > - "make install" > - internal slirp/dtc/capstone. > > It should be more or less bisectable. I have not tried building > _all_ steps, but I have tried both before and after each major one. > > Build system rebuild rules seem to work reliably. > > After a week or quite intense rebasing, my impression is more or less > the same as last December: Meson looks more daunting, but it is actually > much nicer to work with. > > The diffstat so far is not very favorable, but remember that: > > 1) the series leaves quite a few nearly-obsolete bits in configure, > Makefile and rules.mak (over 200 lines only in the makefiles). > > 2) configure test conversion will be where meson really shines. I > included a couple examples just to show > > meson: convert VNC and dependent libraries to meson > 4 files changed, 44 insertions(+), 134 deletions(-) > > meson: move SDL and SDL-image detection to meson > 5 files changed, 30 insertions(+), 144 deletions(-) > > meson: replace create-config with meson configure_file > 6 files changed, 80 insertions(+), 168 deletions(-) > > 3) the idea behind using Makefile generators is to have stable > code written in a high-level language instead of Makefile magic > that tends to grow by accretion. So even though ninjatool is > large at 1000 lines of Python, it can already be considered mature > or even "done". It had only ~15 lines changed since the last post, > and whenever debugging meson.build issues looking at build.ninja has > always (literally!) been enough. > > Available on git://github.com/bonzini/qemu branch meson-poc-next.
Paolo Bonzini <pbonzini@redhat.com> writes: > This the more or less final version of the Meson conversion. Due to > the sheer size of the series you have been CCed only on the cover > letter. Perfect timing: right before I drop off for two weeks of vacation. I'm excused! *Maniacal laughter* > The series reaches the point where Makefile.target and unnest-vars > can be removed, and all builds become non-recursive. I have also > converted parts of the testsuite, notably qtest since it is needed > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > 2) moving the rest of installation to meson (for which I have patches); > 3) moving feature detection from configure to meson. > > Things I still haven't tested: > - fuzzing > - non-x86/Linux builds > - static builds > - Docker and VM builds > > Things I have checked: > - x86 builds > - modules > - "make install" > - internal slirp/dtc/capstone. Have you run it through our CI? > It should be more or less bisectable. I have not tried building > _all_ steps, but I have tried both before and after each major one. > > Build system rebuild rules seem to work reliably. Is it faster in common build scenarios? > After a week or quite intense rebasing, my impression is more or less > the same as last December: Meson looks more daunting, but it is actually > much nicer to work with. Not a particularly high bar to cross: our Makefiles are full of the kind of black magic that keeps simple things simple (which is quite an achievement; kudos!), and makes not-so-simple things really hard. I think it's now time to plan the end game, preferably without even more weeks of intense rebasing. Do we have consensus to move forward with Meson? If yes, I'd like to propose to aim for merging as early as practical in the 5.2 cycle. Rationale: rebasing build system changes on top of the Meson work is probably easier than rebasing the Meson work, and avoids turning Paolo into an overworked bottleneck. In more detail: 1. Pick a tentative deadline. 2. Cover the testing gaps and get as much review as we can until then. Fix defects as we go. 3. If the known defects are expected to disrupt others too much, goto 1. Do not worry about unknown defects at this point. 4. Merge. 5. Deal with the fallout. Opinions? > The diffstat so far is not very favorable, but remember that: > > 1) the series leaves quite a few nearly-obsolete bits in configure, > Makefile and rules.mak (over 200 lines only in the makefiles). > > 2) configure test conversion will be where meson really shines. I > included a couple examples just to show > > meson: convert VNC and dependent libraries to meson > 4 files changed, 44 insertions(+), 134 deletions(-) > > meson: move SDL and SDL-image detection to meson > 5 files changed, 30 insertions(+), 144 deletions(-) > > meson: replace create-config with meson configure_file > 6 files changed, 80 insertions(+), 168 deletions(-) > > 3) the idea behind using Makefile generators is to have stable > code written in a high-level language instead of Makefile magic > that tends to grow by accretion. So even though ninjatool is > large at 1000 lines of Python, it can already be considered mature > or even "done". It had only ~15 lines changed since the last post, > and whenever debugging meson.build issues looking at build.ninja has > always (literally!) been enough. The major drawback with generating code is usually having to debug the generated code. Your experience of not having to do that is encouraging. > Available on git://github.com/bonzini/qemu branch meson-poc-next.
On 07/08/20 08:53, Cornelia Huck wrote: > So, I was planning to give it a go on s390, but I cannot even build it > on x86 (fails configure): > > Build started at 2020-08-07T08:43:43.873638 > Main binary: /usr/bin/python3 > Build Options: -Doptimization=2 -Ddebug=true -Dwerror=true -Dstrip=true -Db_pie=true -Db_coverage=false -Dsdl=auto -Dsdl_image=auto -Dvnc=enabled -Dvnc_sasl=auto -Dvnc_jpeg=auto -Dvnc_png=auto -Dprefix=/usr/local -Dbindir=/usr/local/bin -Ddatadir=/usr/local/share -Dincludedir=/usr/local/include -Dlibdir=/usr/local/lib -Dlibexecdir=/usr/local/libexec -Dlocalstatedir=/usr/local/var -Dmandir=/usr/local/share/man -Dsysconfdir=/usr/local/etc > Python system: Linux > The Meson build system > Version: 0.52.0 > Source dir: /home/cohuck/git/qemu > Build dir: /home/cohuck/git/qemu/build > Build type: native build > > meson.build:438:22: ERROR: Key must be a string. > config_target_h += {target: configure_file(output: target + '-config-target.h', > ^ > (Fedora 31, version from your github branch) > > Is there anything special I need to install beyond meson? You probably need to do "git submodule init"/"git submodule update" so that it picks up the in-tree meson (0.55.0). If you want to test on s390, just testing the boot ROM would be great (patch 3). That one does not need Meson at all; the purpose of the patch is just to decouple the boot ROM makefile from rules.mak, which allows to drop some of the contents of rules.mak. Paolo
Could meson can generate CMake file or directly using CMake? cause Cmake have better IDE support. On Fri, Aug 7, 2020 at 2:54 PM Cornelia Huck <cohuck@redhat.com> wrote: > On Thu, 6 Aug 2020 21:13:56 +0200 > Paolo Bonzini <pbonzini@redhat.com> wrote: > > > This the more or less final version of the Meson conversion. Due to > > the sheer size of the series you have been CCed only on the cover > > letter. > > > > The series reaches the point where Makefile.target and unnest-vars > > can be removed, and all builds become non-recursive. I have also > > converted parts of the testsuite, notably qtest since it is needed > > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > > 2) moving the rest of installation to meson (for which I have patches); > > 3) moving feature detection from configure to meson. > > > > Things I still haven't tested: > > - fuzzing > > - non-x86/Linux builds > > So, I was planning to give it a go on s390, but I cannot even build it > on x86 (fails configure): > > Build started at 2020-08-07T08:43:43.873638 > Main binary: /usr/bin/python3 > Build Options: -Doptimization=2 -Ddebug=true -Dwerror=true -Dstrip=true > -Db_pie=true -Db_coverage=false -Dsdl=auto -Dsdl_image=auto -Dvnc=enabled > -Dvnc_sasl=auto -Dvnc_jpeg=auto -Dvnc_png=auto -Dprefix=/usr/local > -Dbindir=/usr/local/bin -Ddatadir=/usr/local/share > -Dincludedir=/usr/local/include -Dlibdir=/usr/local/lib > -Dlibexecdir=/usr/local/libexec -Dlocalstatedir=/usr/local/var > -Dmandir=/usr/local/share/man -Dsysconfdir=/usr/local/etc > Python system: Linux > The Meson build system > Version: 0.52.0 > Source dir: /home/cohuck/git/qemu > Build dir: /home/cohuck/git/qemu/build > Build type: native build > > meson.build:438:22: ERROR: Key must be a string. > config_target_h += {target: configure_file(output: target + > '-config-target.h', > ^ > (Fedora 31, version from your github branch) > > Is there anything special I need to install beyond meson? > > > - static builds > > - Docker and VM builds > > > > Things I have checked: > > - x86 builds > > - modules > > - "make install" > > - internal slirp/dtc/capstone. > > > > It should be more or less bisectable. I have not tried building > > _all_ steps, but I have tried both before and after each major one. > > > > Build system rebuild rules seem to work reliably. > > > > After a week or quite intense rebasing, my impression is more or less > > the same as last December: Meson looks more daunting, but it is actually > > much nicer to work with. > > > > The diffstat so far is not very favorable, but remember that: > > > > 1) the series leaves quite a few nearly-obsolete bits in configure, > > Makefile and rules.mak (over 200 lines only in the makefiles). > > > > 2) configure test conversion will be where meson really shines. I > > included a couple examples just to show > > > > meson: convert VNC and dependent libraries to meson > > 4 files changed, 44 insertions(+), 134 deletions(-) > > > > meson: move SDL and SDL-image detection to meson > > 5 files changed, 30 insertions(+), 144 deletions(-) > > > > meson: replace create-config with meson configure_file > > 6 files changed, 80 insertions(+), 168 deletions(-) > > > > 3) the idea behind using Makefile generators is to have stable > > code written in a high-level language instead of Makefile magic > > that tends to grow by accretion. So even though ninjatool is > > large at 1000 lines of Python, it can already be considered mature > > or even "done". It had only ~15 lines changed since the last post, > > and whenever debugging meson.build issues looking at build.ninja has > > always (literally!) been enough. > > > > Available on git://github.com/bonzini/qemu branch meson-poc-next. > > >
On 07/08/20 10:01, 罗勇刚(Yonggang Luo) wrote: > Could meson can generate CMake file or directly using CMake? > cause Cmake have better IDE support. No, Meson generates ninja files. In QEMU I am translating them to Makefile to aid in bisectability. Paolo
On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: > > > This the more or less final version of the Meson conversion. Due to > > the sheer size of the series you have been CCed only on the cover > > letter. > > Perfect timing: right before I drop off for two weeks of vacation. I'm > excused! *Maniacal laughter* > > > The series reaches the point where Makefile.target and unnest-vars > > can be removed, and all builds become non-recursive. I have also > > converted parts of the testsuite, notably qtest since it is needed > > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > > 2) moving the rest of installation to meson (for which I have patches); > > 3) moving feature detection from configure to meson. > > > > Things I still haven't tested: > > - fuzzing > > - non-x86/Linux builds > > - static builds > > - Docker and VM builds > > > > Things I have checked: > > - x86 builds > > - modules > > - "make install" > > - internal slirp/dtc/capstone. > > Have you run it through our CI? > > > It should be more or less bisectable. I have not tried building > > _all_ steps, but I have tried both before and after each major one. > > > > Build system rebuild rules seem to work reliably. > > Is it faster in common build scenarios? > > > After a week or quite intense rebasing, my impression is more or less > > the same as last December: Meson looks more daunting, but it is actually > > much nicer to work with. > > Not a particularly high bar to cross: our Makefiles are full of the kind > of black magic that keeps simple things simple (which is quite an > achievement; kudos!), and makes not-so-simple things really hard. > > I think it's now time to plan the end game, preferably without even more > weeks of intense rebasing. > > Do we have consensus to move forward with Meson? If yes, I'd like to > propose to aim for merging as early as practical in the 5.2 cycle. > Rationale: rebasing build system changes on top of the Meson work is > probably easier than rebasing the Meson work, and avoids turning Paolo > into an overworked bottleneck. > > In more detail: > > 1. Pick a tentative deadline. I'd suggest we need a bare minimum of half a development cycle to. So if we want it tin 5.2, we need to make a strong push now and over next month to review it and iron out any obvious blocking testing problems. > 2. Cover the testing gaps and get as much review as we can until then. > Fix defects as we go. In terms of testing I'd suggest the minimium bar is likely the GitLab CI and Peter's merge scripts. Anything beyond that is just nice to have. > 3. If the known defects are expected to disrupt others too much, goto 1. > Do not worry about unknown defects at this point. > > 4. Merge. > > 5. Deal with the fallout. Yep, there's no substitute for getting it used for real by a wide range of people, which is why we we need leave ourselves at min 1/2 a dev cycle for this. Regards, Daniel
Any IDE works with meson properly? Does meson have vs code plugin? On Fri, Aug 7, 2020 at 4:11 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > On 07/08/20 10:01, 罗勇刚(Yonggang Luo) wrote: > > Could meson can generate CMake file or directly using CMake? > > cause Cmake have better IDE support. > > No, Meson generates ninja files. In QEMU I am translating them to > Makefile to aid in bisectability. > > Paolo > >
On 07/08/20 09:56, Markus Armbruster wrote: > Paolo Bonzini <pbonzini@redhat.com> writes: > >> This the more or less final version of the Meson conversion. Due to >> the sheer size of the series you have been CCed only on the cover >> letter. > > Perfect timing: right before I drop off for two weeks of vacation. I'm > excused! *Maniacal laughter* > > Have you run it through our CI? Of course not. O:-) > without even more weeks of intense rebasing. FWIW there were only three hard rebases from 5.0 to 5.2: qemu-storage-daemon (by far the hardest), linux-user's syscall_nr.h generation, and fuzzing (easiest except it required conversion of qtest). S I would like to merge this on August 21st. I hope to post a "definitive" verion on August 14th, and hope to work with Peter the next week on getting it to pass his tests. Perhaps that's optimistic though. Depending on when it's ready, I can pick up the series that gets rid of Texinfo, if Peter and yourself don't want to learn Meson just for that. Anyway, I think this is the no-return point: if people say no, I'm not going to push it any further. If people say yes, we'd better merge it quickly and be done with it. I do understand resistance. It's a new tool replacing a 40-year-old standard; build systems are not fancy; and there is a substantial sunken cost. All I can answer is that the line between sunken cost and Stockholm syndrome is a fine one. I cannot say this stuff has been *fun*, but at least the debugging was refreshing compared to Makefiles. Again not a very high bar, but it's something. >> It should be more or less bisectable. I have not tried building >> _all_ steps, but I have tried both before and after each major one. >> >> Build system rebuild rules seem to work reliably. > > Is it faster in common build scenarios? Some oldish numbers: before after ---------------------------------------------------- ../configure 18s 43s ../configure && make -j18 169s 172s make -j18 (do nothing) 4s 4s make -j4 (do nothing) 6.5s 4s touch ../configure && make -j18 52s 62s (does nothing in make) touch ../configure && make -j4 71s 62s (does nothing in make) make clean 19s 2s make -j18 clean 3.5s 2s ---------------------------------------------------- ninja -j18 (do nothing) 1s ninja -t clean 2s ninja -j18 96s (43s+96s=139s) ../configure becomes slower because minikconf.py moved from Make to configure time, and because it has to generate the massive Makefile which it didn't do before. In fact it generates the build rules twice: Meson first generates build.ninja, and then ninjatool turns it into Makefile.ninja. Most of the time is recouped during Make though, and a do nothing "make" become faster, especially at lower -j. This is expected because the massive Makefile (while producing essentially the same rules as before) is parsed directly by Make, without having to execute complex Make macros. It is more visible at lower -j because parsing the non-recursive Makefile is serial, while the current build system uses recursive Makefiles for which the work can be parallelized. ninja is quite a bit faster than Make. It also stores a binary representation of build.ninja, so its do-nothing times are better. We can think of switching to it for the main build, once all tests are converted to Meson. Advantage: it lets us kill large swaths of ninjatool; disadvantage: it introduces an extra dependency. Even before that, developers will be free to alternate between make and ninja. I haven't bothered so far, but then my machine does -j18 and not everyone has that luxury. tl;dr: for now, not much, but it can only improve. This is consistent with this series reaching the "worst mergeable state". My objective was only maintainability and not performance (without regressing on that front) Another useful feature, that can be used more in the future, is integration with external tools such as sparse (now) and clang's static analyzer (later). This is because ninja (and ninjatool) are able to produce a compile_commands.json file that summarizes how to produce the object files for the whole build. > Not a particularly high bar to cross: our Makefiles are full of the kind > of black magic that keeps simple things simple (which is quite an > achievement; kudos!), and makes not-so-simple things really hard. Looking back at the goals: - "it should remain trivial to do things that used to be trivial": achieved though the syntax is more complicated. - it should be "easy to do things that are a matter of cut-and-paste from something that already exist": that would be for example adding a new target, or new tools to contrib. I added AVR and RX for this rebase and it was the least of the problems, so I'd say achieved. - "it should be possible to modify meson.build without knowing [details of the QEMU build system such as ninjatool]": achieved. - it should be "possible to do everything else". Of course some parts of meson.build (QAPI, tracetool, modules and the building the emulator binaries) are complex. The only part that is worse than before is the forwarding "trace.h" headers (patch 4). I have actually thought of a way to fix that, but I am not 100% sure it works so I don't plan on doing it before the merge. - "drop Makefile magic in favor of build rule generators written in high-level languages": achieved >> 3) the idea behind using Makefile generators is to have stable >> code written in a high-level language instead of Makefile magic >> that tends to grow by accretion. So even though ninjatool is >> large at 1000 lines of Python, it can already be considered mature >> or even "done". It had only ~15 lines changed since the last post, >> and whenever debugging meson.build issues looking at build.ninja has >> always (literally!) been enough. > > The major drawback with generating code is usually having to debug the > generated code. Your experience of not having to do that is > encouraging. Yes, that's my point expressed in a succinct way. Paolo
On 07/08/20 10:31, 罗勇刚(Yonggang Luo) wrote:
> Any IDE works with meson properly? Does meson have vs code plugin?
I'm not sure what the plugin would do. However note that even with
Meson, QEMU would be built with "./configure && make".
Paolo
On 8/7/20 10:22 AM, Daniel P. Berrangé wrote: > On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote: >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >>> This the more or less final version of the Meson conversion. Due to >>> the sheer size of the series you have been CCed only on the cover >>> letter. >> >> Perfect timing: right before I drop off for two weeks of vacation. I'm >> excused! *Maniacal laughter* >> >>> The series reaches the point where Makefile.target and unnest-vars >>> can be removed, and all builds become non-recursive. I have also >>> converted parts of the testsuite, notably qtest since it is needed >>> for fuzzing. What's left for _after_ the merge is: 1) unit tests; >>> 2) moving the rest of installation to meson (for which I have patches); >>> 3) moving feature detection from configure to meson. >>> >>> Things I still haven't tested: >>> - fuzzing >>> - non-x86/Linux builds >>> - static builds >>> - Docker and VM builds >>> >>> Things I have checked: >>> - x86 builds >>> - modules >>> - "make install" >>> - internal slirp/dtc/capstone. >> >> Have you run it through our CI? >> >>> It should be more or less bisectable. I have not tried building >>> _all_ steps, but I have tried both before and after each major one. >>> >>> Build system rebuild rules seem to work reliably. >> >> Is it faster in common build scenarios? >> >>> After a week or quite intense rebasing, my impression is more or less >>> the same as last December: Meson looks more daunting, but it is actually >>> much nicer to work with. >> >> Not a particularly high bar to cross: our Makefiles are full of the kind >> of black magic that keeps simple things simple (which is quite an >> achievement; kudos!), and makes not-so-simple things really hard. >> >> I think it's now time to plan the end game, preferably without even more >> weeks of intense rebasing. >> >> Do we have consensus to move forward with Meson? If yes, I'd like to >> propose to aim for merging as early as practical in the 5.2 cycle. >> Rationale: rebasing build system changes on top of the Meson work is >> probably easier than rebasing the Meson work, and avoids turning Paolo >> into an overworked bottleneck. Any merge request not changing buildsys (configure/Makefile), adding new (or moving) .c files shouldn't be a problem. I have that feeling that Meson will have less bottleneck problem than our Perl scripts =) >> >> In more detail: >> >> 1. Pick a tentative deadline. > > I'd suggest we need a bare minimum of half a development cycle to. > So if we want it tin 5.2, we need to make a strong push now and over > next month to review it and iron out any obvious blocking testing > problems. > >> 2. Cover the testing gaps and get as much review as we can until then. >> Fix defects as we go. > > In terms of testing I'd suggest the minimium bar is likely the GitLab CI > and Peter's merge scripts. > > Anything beyond that is just nice to have. > >> 3. If the known defects are expected to disrupt others too much, goto 1. >> Do not worry about unknown defects at this point. >> >> 4. Merge. >> >> 5. Deal with the fallout. > > Yep, there's no substitute for getting it used for real by a wide > range of people, which is why we we need leave ourselves at min > 1/2 a dev cycle for this. Just to clarify, does the "dev cycle" include the freeze window? QEMU produces a release every 17 weeks, the dev cycle is usually 12 weeks then we have 4 (+1) weeks of stabilization for the release. So the plan is to get this merged approximately 6 weeks after the next release, right? Regards, Phil. > > > Regards, > Daniel >
On Thu, 6 Aug 2020 at 20:16, Paolo Bonzini <pbonzini@redhat.com> wrote: > > This the more or less final version of the Meson conversion. Due to > the sheer size of the series you have been CCed only on the cover > letter. Does this work with actually-released versions of Meson yet? I am still not very enthusiastic about the prospect of having to carry around an entire build system in a submodule. That still seems to me to be living closer to the bleeding edge than I would like... -- PMM
On 06/08/2020 21.13, Paolo Bonzini wrote: > This the more or less final version of the Meson conversion. Due to > the sheer size of the series you have been CCed only on the cover > letter. > > The series reaches the point where Makefile.target and unnest-vars > can be removed, and all builds become non-recursive. I have also > converted parts of the testsuite, notably qtest since it is needed > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > 2) moving the rest of installation to meson (for which I have patches); > 3) moving feature detection from configure to meson. > > Things I still haven't tested: > - fuzzing > - non-x86/Linux builds > - static builds > - Docker and VM builds > > Things I have checked: > - x86 builds > - modules > - "make install" > - internal slirp/dtc/capstone. > > It should be more or less bisectable. I have not tried building > _all_ steps, but I have tried both before and after each major one. > > Build system rebuild rules seem to work reliably. > > After a week or quite intense rebasing, my impression is more or less > the same as last December: Meson looks more daunting, but it is actually > much nicer to work with. > > The diffstat so far is not very favorable, but remember that: > > 1) the series leaves quite a few nearly-obsolete bits in configure, > Makefile and rules.mak (over 200 lines only in the makefiles). > > 2) configure test conversion will be where meson really shines. I > included a couple examples just to show > > meson: convert VNC and dependent libraries to meson > 4 files changed, 44 insertions(+), 134 deletions(-) > > meson: move SDL and SDL-image detection to meson > 5 files changed, 30 insertions(+), 144 deletions(-) > > meson: replace create-config with meson configure_file > 6 files changed, 80 insertions(+), 168 deletions(-) > > 3) the idea behind using Makefile generators is to have stable > code written in a high-level language instead of Makefile magic > that tends to grow by accretion. So even though ninjatool is > large at 1000 lines of Python, it can already be considered mature > or even "done". It had only ~15 lines changed since the last post, > and whenever debugging meson.build issues looking at build.ninja has > always (literally!) been enough. > > Available on git://github.com/bonzini/qemu branch meson-poc-next. I just threw your meson-poc-next branch at our CI systems. Observations: 1) If no meson is installed, configure quickly aborts with "ERROR: Meson not found. Use --meson=/path/to/meson|git|internal": https://gitlab.com/huth/qemu/-/jobs/675533520 Could you simply change it to default got git/internal instead (where is the difference between git and internal?), so that we do not have to add a --meson=xxx to all the CI jobs everywhere? 2) With --meson=git added, I also do not get much further: "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' not found" https://gitlab.com/huth/qemu/-/jobs/675546229 Any idea what's going wrong here? 3) macOS build fails in a different way: ../meson.build:1:0: ERROR: Value "gnu++03" for combo option "C++ language standard to use" is not one of the choices. Possible choices are: "none", "c++98", "c++03", "c++11", "c++14", "c++17", "c++1z", "c++2a", "gnu++11", "gnu++14", "gnu++17", "gnu++1z", "gnu++2a". A full log can be found at /private/var/folders/3y/l0z1x3693dl_8n0qybp4dqwh0000gn/T/cirrus-ci-build/build/meson-logs/meson-log.txt ERROR: meson setup failed https://cirrus-ci.com/task/6514035426328576 Maybe we should use gnu++11 for C++ code nowadays? ... we still used gnu++98 in the past since GCC 4.8 (from CentOS/RHEL 7) has only "experimental" support for c++11 ... but since we're soon (in less than a year) going to drop support for that anyway, maybe we could switch it now already to gnu++11 ... ? Thomas
On 07/08/20 10:51, Thomas Huth wrote: > ../meson.build:1:0: ERROR: Value "gnu++03" for combo option "C++ > language standard to use" is not one of the choices. Possible choices > are: "none", "c++98", "c++03", "c++11", "c++14", "c++17", "c++1z", > "c++2a", "gnu++11", "gnu++14", "gnu++17", "gnu++1z", "gnu++2a". > A full log can be found at > /private/var/folders/3y/l0z1x3693dl_8n0qybp4dqwh0000gn/T/cirrus-ci-build/build/meson-logs/meson-log.txt > ERROR: meson setup failed > > https://cirrus-ci.com/task/6514035426328576 > > Maybe we should use gnu++11 for C++ code nowadays? ... we still used > gnu++98 in the past since GCC 4.8 (from CentOS/RHEL 7) has only > "experimental" support for c++11 ... but since we're soon (in less than > a year) going to drop support for that anyway, maybe we could switch it > now already to gnu++11 ... ? Yes, I can. And I'll look at the others, thanks!!! Paolo
Daniel P. Berrangé <berrange@redhat.com> writes: > On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote: [...] >> I think it's now time to plan the end game, preferably without even more >> weeks of intense rebasing. >> >> Do we have consensus to move forward with Meson? If yes, I'd like to >> propose to aim for merging as early as practical in the 5.2 cycle. >> Rationale: rebasing build system changes on top of the Meson work is >> probably easier than rebasing the Meson work, and avoids turning Paolo >> into an overworked bottleneck. >> >> In more detail: >> >> 1. Pick a tentative deadline. > > I'd suggest we need a bare minimum of half a development cycle to. > So if we want it tin 5.2, we need to make a strong push now and over > next month to review it and iron out any obvious blocking testing > problems. I had less than a "now and over next month" (>7 weeks!) in mind. The choice of deadline is really about how much of Paolo's time we are (and he is!) willing to spend on rebasing vs. how much risk of toothing problems in master we are willing to accept. "First thing after 5.2 opens" would be ideal from a "avoid more rebasing" point of view, but it may not be practical. Once the flood gates are open, we can probably just as well wait for the initial flood to subside. >> 2. Cover the testing gaps and get as much review as we can until then. >> Fix defects as we go. > > In terms of testing I'd suggest the minimium bar is likely the GitLab CI > and Peter's merge scripts. > > Anything beyond that is just nice to have. Yup. If you want it not to break in master, get it tested in our gating CI. >> 3. If the known defects are expected to disrupt others too much, goto 1. >> Do not worry about unknown defects at this point. >> >> 4. Merge. >> >> 5. Deal with the fallout. > > Yep, there's no substitute for getting it used for real by a wide > range of people, which is why we we need leave ourselves at min > 1/2 a dev cycle for this. > > > Regards, > Daniel
On 07/08/20 10:49, Peter Maydell wrote: >> This the more or less final version of the Meson conversion. Due to >> the sheer size of the series you have been CCed only on the cover >> letter. > > Does this work with actually-released versions of Meson yet? > I am still not very enthusiastic about the prospect of having > to carry around an entire build system in a submodule. That > still seems to me to be living closer to the bleeding edge > than I would like... Yes it works with 0.55.0, with only a few warnings about possible future incompatibility. Those will be fixed in 0.56.0, where the feature was stabilized without introducing any incompatibility. Carrying around Meson in a submodule was mostly done to let QEMU build transparently on older distros. Removing it is easy (though it would involve modifying the docker files to install the latest meson, so whatever you throw out of the door comes back through the window). Paolo
On Fri, Aug 07, 2020 at 11:02:34AM +0200, Markus Armbruster wrote: > Daniel P. Berrangé <berrange@redhat.com> writes: > > > On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote: > [...] > >> I think it's now time to plan the end game, preferably without even more > >> weeks of intense rebasing. > >> > >> Do we have consensus to move forward with Meson? If yes, I'd like to > >> propose to aim for merging as early as practical in the 5.2 cycle. > >> Rationale: rebasing build system changes on top of the Meson work is > >> probably easier than rebasing the Meson work, and avoids turning Paolo > >> into an overworked bottleneck. > >> > >> In more detail: > >> > >> 1. Pick a tentative deadline. > > > > I'd suggest we need a bare minimum of half a development cycle to. > > So if we want it tin 5.2, we need to make a strong push now and over > > next month to review it and iron out any obvious blocking testing > > problems. > > I had less than a "now and over next month" (>7 weeks!) in mind. To be clear, I'm not recommending we wait that long - I'm just suggesting that is an upper bound after which we'd really need to wait for the dev cycle after. Ideally we would make a strong push to get it merged just 2 weeks after this release, ie by early september. > The choice of deadline is really about how much of Paolo's time we are > (and he is!) willing to spend on rebasing vs. how much risk of toothing > problems in master we are willing to accept. > > "First thing after 5.2 opens" would be ideal from a "avoid more > rebasing" point of view, but it may not be practical. > > Once the flood gates are open, we can probably just as well wait for the > initial flood to subside. All depends how quickly Paolo thinks it get to mergeable state.... Regards, Daniel
On 07/08/2020 11.02, Paolo Bonzini wrote: > On 07/08/20 10:49, Peter Maydell wrote: >>> This the more or less final version of the Meson conversion. Due to >>> the sheer size of the series you have been CCed only on the cover >>> letter. >> >> Does this work with actually-released versions of Meson yet? >> I am still not very enthusiastic about the prospect of having >> to carry around an entire build system in a submodule. That >> still seems to me to be living closer to the bleeding edge >> than I would like... > > Yes it works with 0.55.0, with only a few warnings about possible future > incompatibility. Those will be fixed in 0.56.0, where the feature was > stabilized without introducing any incompatibility. > > Carrying around Meson in a submodule was mostly done to let QEMU build > transparently on older distros. Removing it is easy (though it would > involve modifying the docker files to install the latest meson, so > whatever you throw out of the door comes back through the window). From my point of view, we should keep the meson submodule at least 'till spring next year - then we'll remove support for RHEL7 according to our support policy. Hopefully the other distros will have a recent version of Meson at that point in time. Thomas
On 8/7/20 11:02 AM, Markus Armbruster wrote: > Daniel P. Berrangé <berrange@redhat.com> writes: > >> On Fri, Aug 07, 2020 at 09:56:42AM +0200, Markus Armbruster wrote: > [...] >>> 2. Cover the testing gaps and get as much review as we can until then. >>> Fix defects as we go. >> >> In terms of testing I'd suggest the minimium bar is likely the GitLab CI >> and Peter's merge scripts. >> >> Anything beyond that is just nice to have. > > Yup. If you want it not to break in master, get it tested in our gating > CI. Excellent to catch all the uses not covered by CI! So if something break but CI didn't catch it, we should add a CI job first.
On Fri, Aug 07, 2020 at 11:06:55AM +0200, Thomas Huth wrote: > On 07/08/2020 11.02, Paolo Bonzini wrote: > > On 07/08/20 10:49, Peter Maydell wrote: > >>> This the more or less final version of the Meson conversion. Due to > >>> the sheer size of the series you have been CCed only on the cover > >>> letter. > >> > >> Does this work with actually-released versions of Meson yet? > >> I am still not very enthusiastic about the prospect of having > >> to carry around an entire build system in a submodule. That > >> still seems to me to be living closer to the bleeding edge > >> than I would like... > > > > Yes it works with 0.55.0, with only a few warnings about possible future > > incompatibility. Those will be fixed in 0.56.0, where the feature was > > stabilized without introducing any incompatibility. > > > > Carrying around Meson in a submodule was mostly done to let QEMU build > > transparently on older distros. Removing it is easy (though it would > > involve modifying the docker files to install the latest meson, so > > whatever you throw out of the door comes back through the window). > > From my point of view, we should keep the meson submodule at least 'till > spring next year - then we'll remove support for RHEL7 according to our > support policy. Hopefully the other distros will have a recent version > of Meson at that point in time. I very much doubt that will be the case. None of the distros rebase meson in their stable streams. Given our targetted platforms, it is going to be many years (3-4 years) before Meson is present in all the platforms we target. This is not the end of the world, as even 3-4 years is short term in the overall lifetime of QEMU going into the future. Also not exactly worse than bundling all the other stuff we bundle for years. If itis a problem, then perhaps we can finally start shipping a 'qemu.tar.gz' with no bundling at all, and a 'qemu-bundled.tar.gz' with all the 3rd party stuff added. We can, however, expect the distros to have new enough ninja. If we bundle Meson, there's a risk that we see a new shiny feature in next meson, and bump our sub-module to the next release. And again. And again. And again. If we do that we'll never get to a place where we can rely on distro Meson. That will be bad. So I think we need to be very mindful of this and strongly resist the urge to further increase our min meson version in future. FWIW, for libvirt we decided that despite lack of distro support, there was not a compelling reason to bundle meson, because it is really trivial for users to update. e.g. just "pip install". pip install meson --user meson build ninja -C build (possibly need to set $PATH if you don't already have $HOME/.local/bin in your $PATH). Regards, Daniel
On Fri, 7 Aug 2020 at 09:22, Daniel P. Berrangé <berrange@redhat.com> wrote: > In terms of testing I'd suggest the minimium bar is likely the GitLab CI > and Peter's merge scripts. I tried running it through a build test. Fails to build, all hosts: make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/alldbg' config-host.mak is out-of-date, running configure ERROR: Meson not found. Use --meson=/path/to/meson|git|internal make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/alldbg' make: *** No rule to make target 'config-host.mak', needed by 'meson-private/coredata.dat'. Stop. Can we make this Just Work ? thanks -- PMM
On Fri, Aug 07, 2020 at 09:49:23AM +0100, Peter Maydell wrote: > On Thu, 6 Aug 2020 at 20:16, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > This the more or less final version of the Meson conversion. Due to > > the sheer size of the series you have been CCed only on the cover > > letter. > > Does this work with actually-released versions of Meson yet? > I am still not very enthusiastic about the prospect of having > to carry around an entire build system in a submodule. That > still seems to me to be living closer to the bleeding edge > than I would like... Being on the edge is unavoidable if we actually want to use meson any time soon. If we wait for it to be in even 1/2 of the distros we target, then we will be delaying conversion by 1-2 years. I don't think that's desirable, when updating to new enough meson is not much more than runing "pip install meson --user" Regards, Daniel
On Fri, 7 Aug 2020 at 10:19, Daniel P. Berrangé <berrange@redhat.com> wrote: > FWIW, for libvirt we decided that despite lack of distro support, > there was not a compelling reason to bundle meson, because it is > really trivial for users to update. e.g. just "pip install". > > pip install meson --user > meson build > ninja -C build I really hate software build instructions that want me to "just pip install" something. I know nothing about the python out-of-distro packaging process and I don't want the python thing I had to install to build software X to be lurking around on my system forever being picked up and used by random other stuff... thanks -- PMM
On 07/08/20 11:20, Peter Maydell wrote: >> In terms of testing I'd suggest the minimium bar is likely the GitLab CI >> and Peter's merge scripts. > I tried running it through a build test. Fails to build, all hosts: > > make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/alldbg' > config-host.mak is out-of-date, running configure > > ERROR: Meson not found. Use --meson=/path/to/meson|git|internal > > make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/alldbg' > make: *** No rule to make target 'config-host.mak', needed by > 'meson-private/coredata.dat'. Stop. > > > Can we make this Just Work ? Yes, looks like configure is not doing "git submodule update" the right way. I'll debug it. Paolo
On 07/08/20 11:18, Daniel P. Berrangé wrote: > If we bundle Meson, there's a risk that we see a new shiny feature > in next meson, and bump our sub-module to the next release. And > again. And again. And again. If we do that we'll never get to a > place where we can rely on distro Meson. That will be bad. > > So I think we need to be very mindful of this and strongly resist > the urge to further increase our min meson version in future. Agreed. Marc-André has a couple patches left, but they're just nice to have. Another possibility could be adding first-class Sphinx support to Meson (e.g. parsing the conf.py file to figure out the manpages directly). Otherwise, 0.55.0 (or 0.56.0 if we want to avoid the warnings) should have all that we need, and we're already doing some pretty complicated things. Paolo
On 07/08/20 10:51, Thomas Huth wrote: > 2) With --meson=git added, I also do not get much further: > "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' > not found" > > https://gitlab.com/huth/qemu/-/jobs/675546229 > > Any idea what's going wrong here? This is also a submodule not being initialized, ui/keycodemapdb/tools/keymap-gen comes from a submodule. Paolo
On Fri, 7 Aug 2020 09:59:57 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > On 07/08/20 08:53, Cornelia Huck wrote: > > So, I was planning to give it a go on s390, but I cannot even build it > > on x86 (fails configure): > > > > Build started at 2020-08-07T08:43:43.873638 > > Main binary: /usr/bin/python3 > > Build Options: -Doptimization=2 -Ddebug=true -Dwerror=true -Dstrip=true -Db_pie=true -Db_coverage=false -Dsdl=auto -Dsdl_image=auto -Dvnc=enabled -Dvnc_sasl=auto -Dvnc_jpeg=auto -Dvnc_png=auto -Dprefix=/usr/local -Dbindir=/usr/local/bin -Ddatadir=/usr/local/share -Dincludedir=/usr/local/include -Dlibdir=/usr/local/lib -Dlibexecdir=/usr/local/libexec -Dlocalstatedir=/usr/local/var -Dmandir=/usr/local/share/man -Dsysconfdir=/usr/local/etc > > Python system: Linux > > The Meson build system > > Version: 0.52.0 > > Source dir: /home/cohuck/git/qemu > > Build dir: /home/cohuck/git/qemu/build > > Build type: native build > > > > meson.build:438:22: ERROR: Key must be a string. > > config_target_h += {target: configure_file(output: target + '-config-target.h', > > ^ > > (Fedora 31, version from your github branch) > > > > Is there anything special I need to install beyond meson? > > You probably need to do "git submodule init"/"git submodule update" so > that it picks up the in-tree meson (0.55.0). Thanks, that is getting me further. I still seem to be holding it wrong in different places, though... - on an x86 system, configure fails with: ../meson.build:1257:3: ERROR: Key CONFIG_QEMU_PRIVATE_XTS is not in dict - on an s390x system, it mostly builds, but I end up with a bunch of link errors for libblock.fa, where it fails to find various ZSTD_ symbols > > If you want to test on s390, just testing the boot ROM would be great > (patch 3). That one does not need Meson at all; the purpose of the > patch is just to decouple the boot ROM makefile from rules.mak, which > allows to drop some of the contents of rules.mak. I gave it a try; no errors, but then I realized that the image does not seem to get rebuilt? I'll double check later.
On 07/08/2020 11.31, Paolo Bonzini wrote: > On 07/08/20 10:51, Thomas Huth wrote: >> 2) With --meson=git added, I also do not get much further: >> "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' >> not found" >> >> https://gitlab.com/huth/qemu/-/jobs/675546229 >> >> Any idea what's going wrong here? > > This is also a submodule not being initialized, > ui/keycodemapdb/tools/keymap-gen comes from a submodule. Ok. I've added a hack to my configure script to checkout the submodules, but still, it does not compile yet: ../tools/virtiofsd/meson.build:1:0: ERROR: Unknown variable "libvhost_user". https://gitlab.com/huth/qemu/-/jobs/675665455 Thomas
On 07/08/2020 11.45, Thomas Huth wrote: > On 07/08/2020 11.31, Paolo Bonzini wrote: >> On 07/08/20 10:51, Thomas Huth wrote: >>> 2) With --meson=git added, I also do not get much further: >>> "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' >>> not found" >>> >>> https://gitlab.com/huth/qemu/-/jobs/675546229 >>> >>> Any idea what's going wrong here? >> >> This is also a submodule not being initialized, >> ui/keycodemapdb/tools/keymap-gen comes from a submodule. > > Ok. I've added a hack to my configure script to checkout the submodules, > but still, it does not compile yet: > > ../tools/virtiofsd/meson.build:1:0: ERROR: Unknown variable > "libvhost_user". > https://gitlab.com/huth/qemu/-/jobs/675665455 At least the Debian container started to compile, but then fails here: ../hw/display/virtio-gpu.c:43:10: fatal error: virglrenderer.h: No such file or directory https://gitlab.com/huth/qemu/-/jobs/675665451 Thomas
On 07/08/20 11:45, Thomas Huth wrote: > On 07/08/2020 11.31, Paolo Bonzini wrote: >> On 07/08/20 10:51, Thomas Huth wrote: >>> 2) With --meson=git added, I also do not get much further: >>> "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' >>> not found" >>> >>> https://gitlab.com/huth/qemu/-/jobs/675546229 >>> >>> Any idea what's going wrong here? >> >> This is also a submodule not being initialized, >> ui/keycodemapdb/tools/keymap-gen comes from a submodule. > > Ok. I've added a hack to my configure script to checkout the submodules, > but still, it does not compile yet: > > ../tools/virtiofsd/meson.build:1:0: ERROR: Unknown variable > "libvhost_user". > https://gitlab.com/huth/qemu/-/jobs/675665455 Fixed, thanks: diff --git a/meson.build b/meson.build index 38f1f40..cc96d07 100644 --- a/meson.build +++ b/meson.build @@ -1091,9 +1091,10 @@ if have_tools subdir('contrib/ivshmem-client') subdir('contrib/ivshmem-server') endif + + subdir('tools') endif -subdir('tools') subdir('scripts') subdir('pc-bios') subdir('tests') (This is an example of Meson doing a much stronger check on the validity of the build). Paolo
On 07/08/2020 11.49, Thomas Huth wrote: > On 07/08/2020 11.45, Thomas Huth wrote: >> On 07/08/2020 11.31, Paolo Bonzini wrote: >>> On 07/08/20 10:51, Thomas Huth wrote: >>>> 2) With --meson=git added, I also do not get much further: >>>> "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' >>>> not found" >>>> >>>> https://gitlab.com/huth/qemu/-/jobs/675546229 >>>> >>>> Any idea what's going wrong here? >>> >>> This is also a submodule not being initialized, >>> ui/keycodemapdb/tools/keymap-gen comes from a submodule. >> >> Ok. I've added a hack to my configure script to checkout the submodules, >> but still, it does not compile yet: >> >> ../tools/virtiofsd/meson.build:1:0: ERROR: Unknown variable >> "libvhost_user". >> https://gitlab.com/huth/qemu/-/jobs/675665455 > > At least the Debian container started to compile, but then fails here: > > ../hw/display/virtio-gpu.c:43:10: fatal error: virglrenderer.h: No such > file or directory > https://gitlab.com/huth/qemu/-/jobs/675665451 And yet another error, this time on Travis with --disable-system : ../hw/display/meson.build:42:22: ERROR: Unknown variable "config_all_devices". https://travis-ci.com/github/huth/qemu/jobs/369657010#L1035 Thomas
On 07/08/2020 11.52, Thomas Huth wrote: > On 07/08/2020 11.49, Thomas Huth wrote: >> On 07/08/2020 11.45, Thomas Huth wrote: >>> On 07/08/2020 11.31, Paolo Bonzini wrote: >>>> On 07/08/20 10:51, Thomas Huth wrote: >>>>> 2) With --meson=git added, I also do not get much further: >>>>> "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' >>>>> not found" >>>>> >>>>> https://gitlab.com/huth/qemu/-/jobs/675546229 >>>>> >>>>> Any idea what's going wrong here? >>>> >>>> This is also a submodule not being initialized, >>>> ui/keycodemapdb/tools/keymap-gen comes from a submodule. >>> >>> Ok. I've added a hack to my configure script to checkout the submodules, >>> but still, it does not compile yet: >>> >>> ../tools/virtiofsd/meson.build:1:0: ERROR: Unknown variable >>> "libvhost_user". >>> https://gitlab.com/huth/qemu/-/jobs/675665455 >> >> At least the Debian container started to compile, but then fails here: >> >> ../hw/display/virtio-gpu.c:43:10: fatal error: virglrenderer.h: No such >> file or directory >> https://gitlab.com/huth/qemu/-/jobs/675665451 > > And yet another error, this time on Travis with --disable-system : > > ../hw/display/meson.build:42:22: ERROR: Unknown variable > "config_all_devices". > https://travis-ci.com/github/huth/qemu/jobs/369657010#L1035 FreeBSD fails since dbus-daemon is not found: https://cirrus-ci.com/task/6446150314098688?command=main#L203 macOS now stops because the qemu_nbd variable is not set: https://cirrus-ci.com/task/5038775430545408?command=main#L207 Thomas
On 07/08/2020 11.51, Paolo Bonzini wrote: > On 07/08/20 11:45, Thomas Huth wrote: >> On 07/08/2020 11.31, Paolo Bonzini wrote: >>> On 07/08/20 10:51, Thomas Huth wrote: >>>> 2) With --meson=git added, I also do not get much further: >>>> "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' >>>> not found" >>>> >>>> https://gitlab.com/huth/qemu/-/jobs/675546229 >>>> >>>> Any idea what's going wrong here? >>> >>> This is also a submodule not being initialized, >>> ui/keycodemapdb/tools/keymap-gen comes from a submodule. >> >> Ok. I've added a hack to my configure script to checkout the submodules, >> but still, it does not compile yet: >> >> ../tools/virtiofsd/meson.build:1:0: ERROR: Unknown variable >> "libvhost_user". >> https://gitlab.com/huth/qemu/-/jobs/675665455 > > Fixed, thanks: > > diff --git a/meson.build b/meson.build > index 38f1f40..cc96d07 100644 > --- a/meson.build > +++ b/meson.build > @@ -1091,9 +1091,10 @@ if have_tools > subdir('contrib/ivshmem-client') > subdir('contrib/ivshmem-server') > endif > + > + subdir('tools') > endif > > -subdir('tools') > subdir('scripts') > subdir('pc-bios') > subdir('tests') Thanks! With the fix, it now gets a little bit further, but then stops with: ../meson.build:1258:3: ERROR: Key CONFIG_QEMU_PRIVATE_XTS is not in dict https://gitlab.com/huth/qemu/-/jobs/675699330#L130 Thomas
On 07/08/20 11:52, Thomas Huth wrote: >> At least the Debian container started to compile, but then fails here: >> >> ../hw/display/virtio-gpu.c:43:10: fatal error: virglrenderer.h: No such >> file or directory >> https://gitlab.com/huth/qemu/-/jobs/675665451 Likely just a rebase issue: diff --git a/hw/display/meson.build b/hw/display/meson.build index efe18f2..ffcccc0 100644 --- a/hw/display/meson.build +++ b/hw/display/meson.build @@ -81,13 +81,6 @@ if config_all_devices.has_key('CONFIG_VIRTIO_GPU') if_true: virtio_gpu_ss) endif -specific_ss.add(when: [pixman, 'CONFIG_VIRTIO_GPU'], if_true: [files('virtio-gpu-base.c', 'virtio-gpu.c', 'virtio-gpu-3d.c'), virgl]) -specific_ss.add(when: [pixman, 'CONFIG_VHOST_USER_GPU'], if_true: files('vhost-user-gpu.c')) -specific_ss.add(when: ['CONFIG_VIRTIO_GPU', 'CONFIG_VIRTIO_PCI'], if_true: files('virtio-gpu-pci.c')) -specific_ss.add(when: ['CONFIG_VHOST_USER_GPU', 'CONFIG_VIRTIO_PCI'], if_true: files('vhost-user-gpu-pci.c')) -specific_ss.add(when: 'CONFIG_VIRTIO_VGA', if_true: files('virtio-vga.c')) -specific_ss.add(when: 'CONFIG_VHOST_USER_VGA', if_true: files('vhost-user-vga.c')) - specific_ss.add(when: [x11, opengl, 'CONFIG_MILKYMIST_TMU2'], if_true: files('milkymist-tmu2.c')) specific_ss.add(when: 'CONFIG_OMAP', if_true: files('omap_lcdc.c')) > And yet another error, this time on Travis with --disable-system : > > ../hw/display/meson.build:42:22: ERROR: Unknown variable > "config_all_devices". > https://travis-ci.com/github/huth/qemu/jobs/369657010#L1035 diff --git a/meson.build b/meson.build index 5635f8e..ddd73d4 100644 --- a/meson.build +++ b/meson.build @@ -491,10 +491,10 @@ if have_system command: [grepy, '@INPUT@'], ) config_all_devices = keyval.load(config_all_devices_mak) - config_all = config_all_devices else - config_all = {} + config_all_devices = {} endif +config_all = config_all_devices config_all += config_host config_all += config_all_disas config_all += { More type checking. I'll finish my current round of testing and push again. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > On 07/08/20 10:31, 罗勇刚(Yonggang Luo) wrote: >> Any IDE works with meson properly? Does meson have vs code plugin? > > I'm not sure what the plugin would do. However note that even with > Meson, QEMU would be built with "./configure && make". One the subject of IDE's my Emacs tooling (counsel-compile) uses a mixture of "make -nqp" and "make help" to probe for potential make targets. I assume these are still probable with the meson generated files?
On 07/08/20 12:02, Thomas Huth wrote: > Thanks! With the fix, it now gets a little bit further, but then stops with: > > ../meson.build:1258:3: ERROR: Key CONFIG_QEMU_PRIVATE_XTS is not in dict > https://gitlab.com/huth/qemu/-/jobs/675699330#L130 diff --git a/meson.build b/meson.build index d14d4bb..5bcfa09 100644 --- a/meson.build +++ b/meson.build @@ -944,12 +944,12 @@ summary_info += {'GNUTLS support': config_host.has_key('CONFIG_GNUTLS')} summary_info += {'libgcrypt': config_host.has_key('CONFIG_GCRYPT')} if config_host.has_key('CONFIG_GCRYPT') summary_info += {' hmac': config_host.has_key('CONFIG_GCRYPT_HMAC')} - summary_info += {' XTS': config_host['CONFIG_QEMU_PRIVATE_XTS'] != 'y'} + summary_info += {' XTS': not config_host.has_key('CONFIG_QEMU_PRIVATE_XTS')} endif # TODO: add back version summary_info += {'nettle': config_host.has_key('CONFIG_NETTLE')} if config_host.has_key('CONFIG_NETTLE') - summary_info += {' XTS': config_host['CONFIG_QEMU_PRIVATE_XTS'] != 'y'} + summary_info += {' XTS': not config_host.has_key('CONFIG_QEMU_PRIVATE_XTS')} endif summary_info += {'libtasn1': config_host.has_key('CONFIG_TASN1')} summary_info += {'PAM': config_host.has_key('CONFIG_AUTH_PAM')} :) Thanks very much. Sorry for the amount of breakage, at least it's all been trivial to fix so far. Paolo
On 07/08/20 12:05, Alex Bennée wrote: >> On 07/08/20 10:31, 罗勇刚(Yonggang Luo) wrote: >>> Any IDE works with meson properly? Does meson have vs code plugin? >> I'm not sure what the plugin would do. However note that even with >> Meson, QEMU would be built with "./configure && make". > One the subject of IDE's my Emacs tooling (counsel-compile) uses a > mixture of "make -nqp" and "make help" to probe for potential make > targets. I assume these are still probable with the meson generated > files? With the generated files yes, I have no idea how counsel-compile would deal with ninja. Paolo
On 07/08/20 12:00, Thomas Huth wrote: > FreeBSD fails since dbus-daemon is not found: > > https://cirrus-ci.com/task/6446150314098688?command=main#L203 > > macOS now stops because the qemu_nbd variable is not set: > > https://cirrus-ci.com/task/5038775430545408?command=main#L207 A little refactoring needed for the latter, while the former is a one-liner. diff --git a/meson.build b/meson.build index dbe1d08..0a24116 100644 --- a/meson.build +++ b/meson.build @@ -1051,12 +1051,14 @@ endif if have_tools qemu_img = executable('qemu-img', [files('qemu-img.c'), hxdep], dependencies: [authz, block, crypto, io, qom, qemuutil], install: true) + qemu_io = executable('qemu-io', files('qemu-io.c'), + dependencies: [block, qemuutil], install: true) + qemu_block_tools = [qemu_img, qemu_io] if host_machine.system() == 'linux' or host_machine.system() == 'sunos' or host_machine.system().endswith('bsd') qemu_nbd = executable('qemu-nbd', files('qemu-nbd.c'), dependencies: [block, qemuutil], install: true) + qemu_block_tools += [qemu_nbd] endif - qemu_io = executable('qemu-io', files('qemu-io.c'), - dependencies: [block, qemuutil], install: true) subdir('storage-daemon') subdir('contrib/rdmacm-mux') diff --git a/tests/qemu-iotests/meson.build b/tests/qemu-iotests/meson.build index 60e81a2..3de09fb 100644 --- a/tests/qemu-iotests/meson.build +++ b/tests/qemu-iotests/meson.build @@ -1,8 +1,10 @@ -dep = [qemu_img, qemu_io, qemu_nbd, emulators] if 'CONFIG_LINUX' in config_host - dep += executable('socket_scm_helper', 'socket_scm_helper.c', - build_by_default: false) + socket_scm_helper = executable('socket_scm_helper', 'socket_scm_helper.c', + build_by_default: false) +else + socket_scm_helper = [] endif -test('qemu-iotests', sh, args: [files('../check-block.sh')], depends: dep, +test('qemu-iotests', sh, args: [files('../check-block.sh')], + depends: [qemu_block_tools, emulators, socket_scm_helper], suite: 'block', timeout: 10000) diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build index c2601d9..507ee12 100644 --- a/tests/qtest/meson.build +++ b/tests/qtest/meson.build @@ -66,7 +66,7 @@ qtests_i386 = \ 'test-x86-cpuid-compat', 'numa-test'] -dbus_daemon = find_program('dbus-daemon') +dbus_daemon = find_program('dbus-daemon', required: false) if dbus_daemon.found() and config_host.has_key('GDBUS_CODEGEN') # Temporarily disabled due to Patchew failures: #qtests_i386 += ['dbus-vmstate-test'] I pushed again to meson-poc-next, diffstat is configure | 2 +- hw/display/meson.build | 7 ------- meson.build | 19 +++++++++++-------- tests/qemu-iotests/meson.build | 10 ++++++---- tests/qtest/meson.build | 2 +- 5 files changed, 19 insertions(+), 21 deletions(-) Git submodules still not fixed
On Fri, 7 Aug 2020 12:08:17 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > On 07/08/20 12:02, Thomas Huth wrote: > > Thanks! With the fix, it now gets a little bit further, but then stops with: > > > > ../meson.build:1258:3: ERROR: Key CONFIG_QEMU_PRIVATE_XTS is not in dict > > https://gitlab.com/huth/qemu/-/jobs/675699330#L130 > > diff --git a/meson.build b/meson.build > index d14d4bb..5bcfa09 100644 > --- a/meson.build > +++ b/meson.build > @@ -944,12 +944,12 @@ summary_info += {'GNUTLS support': config_host.has_key('CONFIG_GNUTLS')} > summary_info += {'libgcrypt': config_host.has_key('CONFIG_GCRYPT')} > if config_host.has_key('CONFIG_GCRYPT') > summary_info += {' hmac': config_host.has_key('CONFIG_GCRYPT_HMAC')} > - summary_info += {' XTS': config_host['CONFIG_QEMU_PRIVATE_XTS'] != 'y'} > + summary_info += {' XTS': not config_host.has_key('CONFIG_QEMU_PRIVATE_XTS')} > endif > # TODO: add back version > summary_info += {'nettle': config_host.has_key('CONFIG_NETTLE')} > if config_host.has_key('CONFIG_NETTLE') > - summary_info += {' XTS': config_host['CONFIG_QEMU_PRIVATE_XTS'] != 'y'} > + summary_info += {' XTS': not config_host.has_key('CONFIG_QEMU_PRIVATE_XTS')} > endif > summary_info += {'libtasn1': config_host.has_key('CONFIG_TASN1')} > summary_info += {'PAM': config_host.has_key('CONFIG_AUTH_PAM')} That one also seems to have fixed my x86 build woes.
Paolo Bonzini <pbonzini@redhat.com> writes: > On 07/08/20 12:05, Alex Bennée wrote: >>> On 07/08/20 10:31, 罗勇刚(Yonggang Luo) wrote: >>>> Any IDE works with meson properly? Does meson have vs code plugin? >>> I'm not sure what the plugin would do. However note that even with >>> Meson, QEMU would be built with "./configure && make". >> One the subject of IDE's my Emacs tooling (counsel-compile) uses a >> mixture of "make -nqp" and "make help" to probe for potential make >> targets. I assume these are still probable with the meson generated >> files? > > With the generated files yes, I have no idea how counsel-compile would > deal with ninja. It's probing for top-level targets. So if there is a way to query ninja for that it's easy enough to write a probe to collect them. The make -nqp stuff is a little janky but basically greps for .PHONY patterns and assumes a .PHONY target is a top level target. The help parsing is pure regexery: (defvar counsel-compile-phony-pattern "^\\.PHONY:[\t ]+\\(.+\\)$" "Regexp for extracting phony targets from Makefiles.") (defvar counsel-compile-help-pattern "\\(?:^\\(\\*\\)?[[:space:]]+\\([^[:space:]]+\\)[[:space:]]+-\\)" "Regexp for extracting help targets from a make help call.") I guess I'll have to see what: ninja -t targets all lists.
On 07/08/20 12:25, Cornelia Huck wrote: > On Fri, 7 Aug 2020 12:08:17 +0200 > Paolo Bonzini <pbonzini@redhat.com> wrote: > >> On 07/08/20 12:02, Thomas Huth wrote: >>> Thanks! With the fix, it now gets a little bit further, but then stops with: >>> >>> ../meson.build:1258:3: ERROR: Key CONFIG_QEMU_PRIVATE_XTS is not in dict >>> https://gitlab.com/huth/qemu/-/jobs/675699330#L130 >> >> diff --git a/meson.build b/meson.build >> index d14d4bb..5bcfa09 100644 >> --- a/meson.build >> +++ b/meson.build >> @@ -944,12 +944,12 @@ summary_info += {'GNUTLS support': config_host.has_key('CONFIG_GNUTLS')} >> summary_info += {'libgcrypt': config_host.has_key('CONFIG_GCRYPT')} >> if config_host.has_key('CONFIG_GCRYPT') >> summary_info += {' hmac': config_host.has_key('CONFIG_GCRYPT_HMAC')} >> - summary_info += {' XTS': config_host['CONFIG_QEMU_PRIVATE_XTS'] != 'y'} >> + summary_info += {' XTS': not config_host.has_key('CONFIG_QEMU_PRIVATE_XTS')} >> endif >> # TODO: add back version >> summary_info += {'nettle': config_host.has_key('CONFIG_NETTLE')} >> if config_host.has_key('CONFIG_NETTLE') >> - summary_info += {' XTS': config_host['CONFIG_QEMU_PRIVATE_XTS'] != 'y'} >> + summary_info += {' XTS': not config_host.has_key('CONFIG_QEMU_PRIVATE_XTS')} >> endif >> summary_info += {'libtasn1': config_host.has_key('CONFIG_TASN1')} >> summary_info += {'PAM': config_host.has_key('CONFIG_AUTH_PAM')} > > That one also seems to have fixed my x86 build woes. Great. That was an unusual case of things breaking with *newer* distros (that do have XTS in the system library). Please just pull again as that has many fixes for other things that Thomas reported. FWIW, impressions on reviewing these mini patches are very welcome. After all reviewing small patches is more common than reviewing the whole 140 patch thing, so it's important that people can quickly get an idea of what's going on in a small patch. Paolo
On 07/08/2020 12.20, Paolo Bonzini wrote: > On 07/08/20 12:00, Thomas Huth wrote: >> FreeBSD fails since dbus-daemon is not found: >> >> https://cirrus-ci.com/task/6446150314098688?command=main#L203 >> >> macOS now stops because the qemu_nbd variable is not set: >> >> https://cirrus-ci.com/task/5038775430545408?command=main#L207 > > A little refactoring needed for the latter, while the former is a one-liner. Thanks! Now, both, macOS and FreeBSD builds stop with: ../tests/qtest/meson.build:204:0: ERROR: Unknown variable "dbus_vmstate1". https://cirrus-ci.com/task/6220295902068736?command=main#L210 Thomas
Peter Maydell <peter.maydell@linaro.org> writes: > On Fri, 7 Aug 2020 at 09:22, Daniel P. Berrangé <berrange@redhat.com> wrote: >> In terms of testing I'd suggest the minimium bar is likely the GitLab CI >> and Peter's merge scripts. > > I tried running it through a build test. Fails to build, all hosts: > > make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/alldbg' > config-host.mak is out-of-date, running configure > > ERROR: Meson not found. Use --meson=/path/to/meson|git|internal > > make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/alldbg' > make: *** No rule to make target 'config-host.mak', needed by > 'meson-private/coredata.dat'. Stop. I note all the CI jobs have failed on building as well. I think maybe we should auto-default to --meson=git unless the user makes an explicit choice. > > > Can we make this Just Work ? > > thanks > -- PMM
On 07/08/20 12:29, Alex Bennée wrote: > It's probing for top-level targets. So if there is a way to query ninja > for that it's easy enough to write a probe to collect them. The make > -nqp stuff is a little janky but basically greps for .PHONY patterns and > assumes a .PHONY target is a top level target. The help parsing is pure > regexery: > > (defvar counsel-compile-phony-pattern "^\\.PHONY:[\t ]+\\(.+\\)$" > "Regexp for extracting phony targets from Makefiles.") > > (defvar counsel-compile-help-pattern > "\\(?:^\\(\\*\\)?[[:space:]]+\\([^[:space:]]+\\)[[:space:]]+-\\)" > "Regexp for extracting help targets from a make help call.") > > I guess I'll have to see what: > > ninja -t targets all It would have to grep for "^(.+): phony$". Paolo
On Fri, 7 Aug 2020 at 11:53, Alex Bennée <alex.bennee@linaro.org> wrote: > I note all the CI jobs have failed on building as well. I think maybe we > should auto-default to --meson=git unless the user makes an explicit > choice. Our usual approach with other submodules is "system version if it's good enough, otherwise use the submodule copy". -- PMM
On 07/08/20 12:52, Thomas Huth wrote: > Thanks! Now, both, macOS and FreeBSD builds stop with: > > ../tests/qtest/meson.build:204:0: ERROR: Unknown variable "dbus_vmstate1". > https://cirrus-ci.com/task/6220295902068736?command=main#L210 diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build index 507ee126e7..9a7daad59d 100644 --- a/tests/qtest/meson.build +++ b/tests/qtest/meson.build @@ -76,7 +76,9 @@ if dbus_daemon.found() and config_host.has_key('GDBUS_CODEGEN') command: [config_host['GDBUS_CODEGEN'], '@INPUT@', '--interface-prefix', 'org.qemu', - '--generate-c-code', '@BASENAME@']) + '--generate-c-code', '@BASENAME@']).to_list() +else + dbus_vmstate1 = [] endif qtests_x86_64 = qtests_i386 @@ -207,7 +209,7 @@ extra_qtest_srcs = { 'cdrom-test': files('boot-sector.c'), 'migration-test': files('migration-helpers.c'), 'ivshmem-test': files('../../contrib/ivshmem-server/ivshmem-server.c'), - 'dbus-vmstate-test': files('migration-helpers.c') + dbus_vmstate1.to_list(), + 'dbus-vmstate-test': files('migration-helpers.c') + dbus_vmstate1, 'vmgenid-test': files('boot-sector.c', 'acpi-utils.c'), 'tpm-crb-swtpm-test': files('tpm-emu.c', 'tpm-util.c', 'tpm-tests.c'), 'tpm-crb-test': files('tpm-emu.c', 'tpm-util.c', 'tpm-tests.c'), Easy peasy lemon squeezy! :) Paolo
Peter Maydell <peter.maydell@linaro.org> writes: > On Fri, 7 Aug 2020 at 10:19, Daniel P. Berrangé <berrange@redhat.com> wrote: >> FWIW, for libvirt we decided that despite lack of distro support, >> there was not a compelling reason to bundle meson, because it is >> really trivial for users to update. e.g. just "pip install". >> >> pip install meson --user >> meson build >> ninja -C build > > I really hate software build instructions that want me to > "just pip install" something. I know nothing about the > python out-of-distro packaging process and I don't want > the python thing I had to install to build software X > to be lurking around on my system forever being picked > up and used by random other stuff... I have the same feeling (although I'm a bit of hypocrite given the 7 binaries in .local/bin I have). This was the reason we pushed to have avocado build itself in a venv as part of the build system. I don't see meson can't do something similar if it has to (although the git submodule probably works just as well). > > thanks > -- PMM
On Fri, 7 Aug 2020 11:35:57 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > On Fri, 7 Aug 2020 09:59:57 +0200 > Paolo Bonzini <pbonzini@redhat.com> wrote: > - on an s390x system, it mostly builds, but I end up with a bunch of > link errors for libblock.fa, where it fails to find various ZSTD_ > symbols Still happening after switching to the latest version of your branch. > > > > > If you want to test on s390, just testing the boot ROM would be great > > (patch 3). That one does not need Meson at all; the purpose of the > > patch is just to decouple the boot ROM makefile from rules.mak, which > > allows to drop some of the contents of rules.mak. > > I gave it a try; no errors, but then I realized that the image does not > seem to get rebuilt? I'll double check later. I re-tried with a pristine build directory (on a different system), and it does not look good: BUILD pc-bios/s390-ccw/s390-ccw.elf cc: error: start.o: No such file or directory cc: error: main.o: No such file or directory cc: error: bootmap.o: No such file or directory cc: error: jump2ipl.o: No such file or directory cc: error: sclp.o: No such file or directory cc: error: menu.o: No such file or directory cc: error: virtio.o: No such file or directory cc: error: virtio-scsi.o: No such file or directory cc: error: virtio-blkdev.o: No such file or directory cc: error: libc.o: No such file or directory cc: error: cio.o: No such file or directory cc: error: dasd-ipl.o: No such file or directory make[1]: *** [Makefile:85: s390-ccw.elf] Error 1 make: *** [Makefile:576: pc-bios/s390-ccw/all] Error 2
On 07/08/2020 13.04, Paolo Bonzini wrote: > On 07/08/20 12:52, Thomas Huth wrote: >> Thanks! Now, both, macOS and FreeBSD builds stop with: >> >> ../tests/qtest/meson.build:204:0: ERROR: Unknown variable "dbus_vmstate1". >> https://cirrus-ci.com/task/6220295902068736?command=main#L210 > > Easy peasy lemon squeezy! :) Nice, we're getting there, now macOS starts compiling, but then fails here: ../contrib/libvhost-user/libvhost-user.c:27:10: fatal error: 'sys/eventfd.h' file not found ../contrib/libvhost-user/libvhost-user.h:21:10: fatal error: 'linux/vhost.h' file not found https://cirrus-ci.com/task/5170197348745216?command=main#L810 (and FWIW, there are some weird "file: ... has no symbols" earlier in the log when running AR on the capstone files) Thomas
On 07/08/20 14:20, Thomas Huth wrote: > Nice, we're getting there, now macOS starts compiling, but then fails here: > > ../contrib/libvhost-user/libvhost-user.c:27:10: fatal error: > 'sys/eventfd.h' file not found > ../contrib/libvhost-user/libvhost-user.h:21:10: fatal error: > 'linux/vhost.h' file not found > https://cirrus-ci.com/task/5170197348745216?command=main#L810 > > (and FWIW, there are some weird "file: ... has no symbols" earlier in > the log when running AR on the capstone files) It's not supposed to build at all. I'll check the "AR" errors and Conny's reported zstd failure. Paolo
On 07/08/20 14:20, Thomas Huth wrote: > On 07/08/2020 13.04, Paolo Bonzini wrote: >> On 07/08/20 12:52, Thomas Huth wrote: >>> Thanks! Now, both, macOS and FreeBSD builds stop with: >>> >>> ../tests/qtest/meson.build:204:0: ERROR: Unknown variable "dbus_vmstate1". >>> https://cirrus-ci.com/task/6220295902068736?command=main#L210 >> Easy peasy lemon squeezy! :) > Nice, we're getting there, now macOS starts compiling, but then fails here: > > ../contrib/libvhost-user/libvhost-user.c:27:10: fatal error: > 'sys/eventfd.h' file not found > ../contrib/libvhost-user/libvhost-user.h:21:10: fatal error: > 'linux/vhost.h' file not found > https://cirrus-ci.com/task/5170197348745216?command=main#L810 > > (and FWIW, there are some weird "file: ... has no symbols" earlier in > the log when running AR on the capstone files) This one is interesting, the vhost-user samples have never been built by default so they have always been broken on macOS. So that will be a bugfix. Paolo
Paolo Bonzini <pbonzini@redhat.com> writes: > On 07/08/20 09:56, Markus Armbruster wrote: >> Paolo Bonzini <pbonzini@redhat.com> writes: >> >>> This the more or less final version of the Meson conversion. Due to >>> the sheer size of the series you have been CCed only on the cover >>> letter. >> >> Perfect timing: right before I drop off for two weeks of vacation. I'm >> excused! *Maniacal laughter* >> >> Have you run it through our CI? > > Of course not. O:-) > >> without even more weeks of intense rebasing. > > FWIW there were only three hard rebases from 5.0 to 5.2: > qemu-storage-daemon (by far the hardest), linux-user's syscall_nr.h > generation, and fuzzing (easiest except it required conversion of qtest). S > > I would like to merge this on August 21st. I hope to post a > "definitive" verion on August 14th, and hope to work with Peter the next > week on getting it to pass his tests. Sounds good to me. > Perhaps that's optimistic though. If it's not ready then, we pick another date and try again. > Depending on when it's ready, I can pick up the series that gets rid of > Texinfo, if Peter and yourself don't want to learn Meson just for that. I appreciate the offer. I figure I'll eventually have to learn some Meson anyway. Still, having to learn it *now* to unblock that series may be inconvenient. > Anyway, I think this is the no-return point: if people say no, I'm not > going to push it any further. If people say yes, we'd better merge it > quickly and be done with it. > > I do understand resistance. It's a new tool replacing a 40-year-old > standard; build systems are not fancy; and there is a substantial sunken > cost. All I can answer is that the line between sunken cost and > Stockholm syndrome is a fine one. I cannot say this stuff has been > *fun*, but at least the debugging was refreshing compared to Makefiles. > Again not a very high bar, but it's something. I'm willing to trust your judgement on this one. I'm notoriously conservative in my choice of tools, and GNU Make is a much better tool than some people give it credit for, but I've long felt we've pushed it beyond its limits. [...]
On Fri, 7 Aug 2020 at 14:55, Markus Armbruster <armbru@redhat.com> wrote: > I'm notoriously conservative in my choice of tools, and GNU Make is a > much better tool than some people give it credit for, but I've long felt > we've pushed it beyond its limits. The thing is, it feels somewhat like we're already pushing Meson beyond *its* limits instead... (it can't do everything we want it to, we've already had to get at least one new feature added upstream for our benefit, and in other places we're having to change our existing conventions to placate Meson). This would be an easier sell if it was "this is all straightforward and Meson has all the functionality we need". I admit that I'm partly feeling a bit more conservative about tooling right now because we just switched the docs to Sphinx and Sphinx has turned out to have some annoying problems we didn't foresee. So taking another tool from the Python universe isn't hugely appealing. (This is not a 'nak'; I'm just expressing my unease.) thanks -- PMM
On Thu, Aug 06, 2020 at 09:13:56PM +0200, Paolo Bonzini wrote: > This the more or less final version of the Meson conversion. Due to > the sheer size of the series you have been CCed only on the cover > letter. > > The series reaches the point where Makefile.target and unnest-vars > can be removed, and all builds become non-recursive. I have also > converted parts of the testsuite, notably qtest since it is needed > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > 2) moving the rest of installation to meson (for which I have patches); > 3) moving feature detection from configure to meson. > Available on git://github.com/bonzini/qemu branch meson-poc-next. I built with ../configure --target-list=x86_64-softmmu on current git master (e1d322c40524d2c544d1fcd37b267d106d16d328) and on meson-poc-next (4877fbc31ecc2dd9705036628b0e53b1b2414045) and compared the binaries. I'm using Fedora 31 with Meson 0.55.0 -help output has changed in the version string < QEMU emulator version 5.0.93 (v5.1.0-rc3) --- > QEMU emulator version 5.0.93 New binaries have lost a bunch of libraries they previously linked to. This isn't neccessarily a bug, if the old make code was incorrectly adding too many libraries. >>>>qemu-system-x86_64<<<< < libibumad.so.3 < libxenguest.so.4.12 < libxml2.so.2 >>>>qemu-bridge-helper<<<< < libdl.so.2 < libffi.so.6 < libgcc_s.so.1 < libgmp.so.10 < libgnutls.so.30 < libgthread-2.0.so.0 < libhogweed.so.5 < libidn2.so.0 < libm.so.6 < libnettle.so.7 < libp11-kit.so.0 < librt.so.1 < libstdc++.so.6 < libtasn1.so.6 < libunistring.so.2 < libutil.so.1 < libz.so.1 >>>>qemu-edid<<<< < libcap-ng.so.0 < libdl.so.2 < libffi.so.6 < libgcc_s.so.1 < libgmp.so.10 < libgnutls.so.30 < libgthread-2.0.so.0 < libhogweed.so.5 < libidn2.so.0 < libnettle.so.7 < libp11-kit.so.0 < librt.so.1 < libstdc++.so.6 < libtasn1.so.6 < libunistring.so.2 < libutil.so.1 < libz.so.1 >>>>qemu-io<<<< < libgthread-2.0.so.0 < liblzma.so.5 < libutil.so.1 < libxml2.so.2 >>>>qemu-nbd<<<< < libgthread-2.0.so.0 < liblzma.so.5 < libutil.so.1 < libxml2.so.2 >>>>qemu-pr-helper<<<< < libgthread-2.0.so.0 < libstdc++.so.6 < libutil.so.1 < libz.so.1 Comparing 'make install', I see some differences: < /vroot/usr/local/bin/elf2dmp < /vroot/usr/local/bin/qemu-edid < /vroot/usr/local/bin/qemu-ga < /vroot/usr/local/bin/qemu-storage-daemon > /vroot/usr/local/bin/qemu-pr-helper < /vroot/usr/local/libexec/qemu-pr-helper < /vroot/usr/local/libexec/vhost-user-gpu < /vroot/usr/local/libexec/virtfs-proxy-helper < /vroot/usr/local/libexec/virtiofsd < /vroot/usr/local/share/locale/sv/LC_MESSAGES/qemu.mo Some documentation files have moved - gaining a bogus extra directory component, and others are missing... > /vroot/usr/local/share/doc/qemu/devel/devel/atomics.html > /vroot/usr/local/share/doc/qemu/devel/devel/bitops.html > /vroot/usr/local/share/doc/qemu/devel/devel/.buildinfo > /vroot/usr/local/share/doc/qemu/devel/devel/clocks.html > /vroot/usr/local/share/doc/qemu/devel/devel/decodetree.html > /vroot/usr/local/share/doc/qemu/devel/devel/genindex.html > /vroot/usr/local/share/doc/qemu/devel/devel/index.html > /vroot/usr/local/share/doc/qemu/devel/devel/kconfig.html > /vroot/usr/local/share/doc/qemu/devel/devel/loads-stores.html > /vroot/usr/local/share/doc/qemu/devel/devel/memory.html > /vroot/usr/local/share/doc/qemu/devel/devel/migration.html > /vroot/usr/local/share/doc/qemu/devel/devel/multi-thread-tcg.html > /vroot/usr/local/share/doc/qemu/devel/devel/objects.inv > /vroot/usr/local/share/doc/qemu/devel/devel/reset.html > /vroot/usr/local/share/doc/qemu/devel/devel/s390-dasd-ipl.html > /vroot/usr/local/share/doc/qemu/devel/devel/search.html > /vroot/usr/local/share/doc/qemu/devel/devel/searchindex.js > /vroot/usr/local/share/doc/qemu/devel/devel/secure-coding-practices.html > /vroot/usr/local/share/doc/qemu/devel/devel/stable-process.html > /vroot/usr/local/share/doc/qemu/devel/devel/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/devel/devel/_static/basic.css > /vroot/usr/local/share/doc/qemu/devel/devel/_static/custom.css > /vroot/usr/local/share/doc/qemu/devel/devel/_static/doctools.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/file.png > /vroot/usr/local/share/doc/qemu/devel/devel/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/jquery.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/language_data.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/minus.png > /vroot/usr/local/share/doc/qemu/devel/devel/_static/plus.png > /vroot/usr/local/share/doc/qemu/devel/devel/_static/pygments.css > /vroot/usr/local/share/doc/qemu/devel/devel/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/devel/devel/_static/underscore.js > /vroot/usr/local/share/doc/qemu/devel/devel/tcg.html > /vroot/usr/local/share/doc/qemu/devel/devel/tcg-icount.html > /vroot/usr/local/share/doc/qemu/devel/devel/tcg-plugins.html > /vroot/usr/local/share/doc/qemu/devel/devel/testing.html < /vroot/usr/local/share/doc/qemu/interop/bitmaps.html < /vroot/usr/local/share/doc/qemu/interop/.buildinfo < /vroot/usr/local/share/doc/qemu/interop/dbus.html < /vroot/usr/local/share/doc/qemu/interop/dbus-vmstate.html < /vroot/usr/local/share/doc/qemu/interop/genindex.html < /vroot/usr/local/share/doc/qemu/interop/index.html < /vroot/usr/local/share/doc/qemu/interop/live-block-operations.html < /vroot/usr/local/share/doc/qemu/interop/objects.inv < /vroot/usr/local/share/doc/qemu/interop/pr-helper.html < /vroot/usr/local/share/doc/qemu/interop/qemu-ga.html > /vroot/usr/local/share/doc/qemu/interop/interop/bitmaps.html > /vroot/usr/local/share/doc/qemu/interop/interop/.buildinfo > /vroot/usr/local/share/doc/qemu/interop/interop/dbus.html > /vroot/usr/local/share/doc/qemu/interop/interop/dbus-vmstate.html > /vroot/usr/local/share/doc/qemu/interop/interop/genindex.html > /vroot/usr/local/share/doc/qemu/interop/interop/index.html > /vroot/usr/local/share/doc/qemu/interop/interop/live-block-operations.html > /vroot/usr/local/share/doc/qemu/interop/interop/objects.inv > /vroot/usr/local/share/doc/qemu/interop/interop/pr-helper.html > /vroot/usr/local/share/doc/qemu/interop/interop/qemu-ga.html > /vroot/usr/local/share/doc/qemu/interop/interop/search.html > /vroot/usr/local/share/doc/qemu/interop/interop/searchindex.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/interop/interop/_static/basic.css > /vroot/usr/local/share/doc/qemu/interop/interop/_static/custom.css > /vroot/usr/local/share/doc/qemu/interop/interop/_static/doctools.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/file.png > /vroot/usr/local/share/doc/qemu/interop/interop/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/jquery.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/language_data.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/minus.png > /vroot/usr/local/share/doc/qemu/interop/interop/_static/plus.png > /vroot/usr/local/share/doc/qemu/interop/interop/_static/pygments.css > /vroot/usr/local/share/doc/qemu/interop/interop/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/interop/interop/_static/underscore.js > /vroot/usr/local/share/doc/qemu/interop/interop/vhost-user-gpu.html > /vroot/usr/local/share/doc/qemu/interop/interop/vhost-user.html > /vroot/usr/local/share/doc/qemu/interop/interop/vhost-vdpa.html > /vroot/usr/local/share/doc/qemu/interop/qemu-ga-ref.info > /vroot/usr/local/share/doc/qemu/interop/qemu-qmp-ref.info < /vroot/usr/local/share/doc/qemu/interop/search.html < /vroot/usr/local/share/doc/qemu/interop/searchindex.js < /vroot/usr/local/share/doc/qemu/interop/_static/alabaster.css < /vroot/usr/local/share/doc/qemu/interop/_static/basic.css < /vroot/usr/local/share/doc/qemu/interop/_static/custom.css < /vroot/usr/local/share/doc/qemu/interop/_static/doctools.js < /vroot/usr/local/share/doc/qemu/interop/_static/documentation_options.js < /vroot/usr/local/share/doc/qemu/interop/_static/file.png < /vroot/usr/local/share/doc/qemu/interop/_static/jquery-3.2.1.js < /vroot/usr/local/share/doc/qemu/interop/_static/jquery.js < /vroot/usr/local/share/doc/qemu/interop/_static/language_data.js < /vroot/usr/local/share/doc/qemu/interop/_static/minus.png < /vroot/usr/local/share/doc/qemu/interop/_static/plus.png < /vroot/usr/local/share/doc/qemu/interop/_static/pygments.css < /vroot/usr/local/share/doc/qemu/interop/_static/searchtools.js < /vroot/usr/local/share/doc/qemu/interop/_static/underscore-1.3.1.js < /vroot/usr/local/share/doc/qemu/interop/_static/underscore.js < /vroot/usr/local/share/doc/qemu/interop/vhost-user-gpu.html < /vroot/usr/local/share/doc/qemu/interop/vhost-user.html < /vroot/usr/local/share/doc/qemu/interop/vhost-vdpa.html < /vroot/usr/local/share/doc/qemu/specs/acpi_hest_ghes.html < /vroot/usr/local/share/doc/qemu/specs/acpi_hw_reduced_hotplug.html < /vroot/usr/local/share/doc/qemu/specs/.buildinfo < /vroot/usr/local/share/doc/qemu/specs/genindex.html < /vroot/usr/local/share/doc/qemu/specs/index.html < /vroot/usr/local/share/doc/qemu/specs/objects.inv < /vroot/usr/local/share/doc/qemu/specs/ppc-spapr-xive.html < /vroot/usr/local/share/doc/qemu/specs/ppc-xive.html < /vroot/usr/local/share/doc/qemu/specs/search.html < /vroot/usr/local/share/doc/qemu/specs/searchindex.js < /vroot/usr/local/share/doc/qemu/specs/_static/alabaster.css < /vroot/usr/local/share/doc/qemu/specs/_static/basic.css < /vroot/usr/local/share/doc/qemu/specs/_static/custom.css < /vroot/usr/local/share/doc/qemu/specs/_static/doctools.js < /vroot/usr/local/share/doc/qemu/specs/_static/documentation_options.js < /vroot/usr/local/share/doc/qemu/specs/_static/file.png < /vroot/usr/local/share/doc/qemu/specs/_static/jquery-3.2.1.js < /vroot/usr/local/share/doc/qemu/specs/_static/jquery.js < /vroot/usr/local/share/doc/qemu/specs/_static/language_data.js < /vroot/usr/local/share/doc/qemu/specs/_static/minus.png < /vroot/usr/local/share/doc/qemu/specs/_static/plus.png < /vroot/usr/local/share/doc/qemu/specs/_static/pygments.css < /vroot/usr/local/share/doc/qemu/specs/_static/searchtools.js < /vroot/usr/local/share/doc/qemu/specs/_static/underscore-1.3.1.js < /vroot/usr/local/share/doc/qemu/specs/_static/underscore.js < /vroot/usr/local/share/doc/qemu/specs/tpm.html < /vroot/usr/local/share/doc/qemu/system/arm/aspeed.html < /vroot/usr/local/share/doc/qemu/system/arm/collie.html < /vroot/usr/local/share/doc/qemu/system/arm/cpu-features.html < /vroot/usr/local/share/doc/qemu/system/arm/digic.html < /vroot/usr/local/share/doc/qemu/system/arm/gumstix.html < /vroot/usr/local/share/doc/qemu/system/arm/integratorcp.html < /vroot/usr/local/share/doc/qemu/system/arm/mps2.html < /vroot/usr/local/share/doc/qemu/system/arm/musca.html < /vroot/usr/local/share/doc/qemu/system/arm/musicpal.html < /vroot/usr/local/share/doc/qemu/system/arm/nseries.html < /vroot/usr/local/share/doc/qemu/system/arm/orangepi.html < /vroot/usr/local/share/doc/qemu/system/arm/palm.html < /vroot/usr/local/share/doc/qemu/system/arm/realview.html < /vroot/usr/local/share/doc/qemu/system/arm/stellaris.html < /vroot/usr/local/share/doc/qemu/system/arm/sx1.html < /vroot/usr/local/share/doc/qemu/system/arm/versatile.html < /vroot/usr/local/share/doc/qemu/system/arm/vexpress.html < /vroot/usr/local/share/doc/qemu/system/arm/virt.html < /vroot/usr/local/share/doc/qemu/system/arm/xscale.html < /vroot/usr/local/share/doc/qemu/system/.buildinfo < /vroot/usr/local/share/doc/qemu/system/build-platforms.html < /vroot/usr/local/share/doc/qemu/system/deprecated.html < /vroot/usr/local/share/doc/qemu/system/gdb.html < /vroot/usr/local/share/doc/qemu/system/genindex.html < /vroot/usr/local/share/doc/qemu/system/images.html < /vroot/usr/local/share/doc/qemu/system/index.html < /vroot/usr/local/share/doc/qemu/system/invocation.html < /vroot/usr/local/share/doc/qemu/system/ivshmem.html < /vroot/usr/local/share/doc/qemu/system/keys.html < /vroot/usr/local/share/doc/qemu/system/license.html < /vroot/usr/local/share/doc/qemu/system/linuxboot.html < /vroot/usr/local/share/doc/qemu/system/managed-startup.html < /vroot/usr/local/share/doc/qemu/system/monitor.html < /vroot/usr/local/share/doc/qemu/system/mux-chardev.html < /vroot/usr/local/share/doc/qemu/system/net.html < /vroot/usr/local/share/doc/qemu/system/objects.inv < /vroot/usr/local/share/doc/qemu/system/qemu-block-drivers.html < /vroot/usr/local/share/doc/qemu/system/qemu-cpu-models.html < /vroot/usr/local/share/doc/qemu/system/qemu-manpage.html < /vroot/usr/local/share/doc/qemu/system/quickstart.html < /vroot/usr/local/share/doc/qemu/system/s390x/3270.html < /vroot/usr/local/share/doc/qemu/system/s390x/css.html < /vroot/usr/local/share/doc/qemu/system/s390x/protvirt.html < /vroot/usr/local/share/doc/qemu/system/s390x/vfio-ap.html < /vroot/usr/local/share/doc/qemu/system/s390x/vfio-ccw.html < /vroot/usr/local/share/doc/qemu/system/search.html < /vroot/usr/local/share/doc/qemu/system/searchindex.js < /vroot/usr/local/share/doc/qemu/system/security.html < /vroot/usr/local/share/doc/qemu/system/_static/alabaster.css < /vroot/usr/local/share/doc/qemu/system/_static/basic.css < /vroot/usr/local/share/doc/qemu/system/_static/custom.css < /vroot/usr/local/share/doc/qemu/system/_static/doctools.js < /vroot/usr/local/share/doc/qemu/system/_static/documentation_options.js < /vroot/usr/local/share/doc/qemu/system/_static/file.png < /vroot/usr/local/share/doc/qemu/system/_static/jquery-3.2.1.js < /vroot/usr/local/share/doc/qemu/system/_static/jquery.js < /vroot/usr/local/share/doc/qemu/system/_static/language_data.js < /vroot/usr/local/share/doc/qemu/system/_static/minus.png < /vroot/usr/local/share/doc/qemu/system/_static/plus.png < /vroot/usr/local/share/doc/qemu/system/_static/pygments.css < /vroot/usr/local/share/doc/qemu/system/_static/searchtools.js < /vroot/usr/local/share/doc/qemu/system/_static/underscore-1.3.1.js < /vroot/usr/local/share/doc/qemu/system/_static/underscore.js < /vroot/usr/local/share/doc/qemu/system/target-arm.html < /vroot/usr/local/share/doc/qemu/system/target-avr.html < /vroot/usr/local/share/doc/qemu/system/target-i386.html < /vroot/usr/local/share/doc/qemu/system/target-m68k.html < /vroot/usr/local/share/doc/qemu/system/target-mips.html < /vroot/usr/local/share/doc/qemu/system/target-ppc.html < /vroot/usr/local/share/doc/qemu/system/target-rx.html < /vroot/usr/local/share/doc/qemu/system/target-s390x.html < /vroot/usr/local/share/doc/qemu/system/targets.html < /vroot/usr/local/share/doc/qemu/system/target-sparc64.html < /vroot/usr/local/share/doc/qemu/system/target-sparc.html < /vroot/usr/local/share/doc/qemu/system/target-xtensa.html < /vroot/usr/local/share/doc/qemu/system/tls.html < /vroot/usr/local/share/doc/qemu/system/usb.html < /vroot/usr/local/share/doc/qemu/system/vnc-security.html < /vroot/usr/local/share/doc/qemu/tools/.buildinfo < /vroot/usr/local/share/doc/qemu/tools/genindex.html < /vroot/usr/local/share/doc/qemu/tools/index.html < /vroot/usr/local/share/doc/qemu/tools/objects.inv < /vroot/usr/local/share/doc/qemu/tools/qemu-img.html < /vroot/usr/local/share/doc/qemu/tools/qemu-nbd.html < /vroot/usr/local/share/doc/qemu/tools/qemu-trace-stap.html < /vroot/usr/local/share/doc/qemu/tools/search.html < /vroot/usr/local/share/doc/qemu/tools/searchindex.js < /vroot/usr/local/share/doc/qemu/tools/_static/alabaster.css < /vroot/usr/local/share/doc/qemu/tools/_static/basic.css < /vroot/usr/local/share/doc/qemu/tools/_static/custom.css < /vroot/usr/local/share/doc/qemu/tools/_static/doctools.js < /vroot/usr/local/share/doc/qemu/tools/_static/documentation_options.js < /vroot/usr/local/share/doc/qemu/tools/_static/file.png < /vroot/usr/local/share/doc/qemu/tools/_static/jquery-3.2.1.js < /vroot/usr/local/share/doc/qemu/tools/_static/jquery.js < /vroot/usr/local/share/doc/qemu/tools/_static/language_data.js < /vroot/usr/local/share/doc/qemu/tools/_static/minus.png < /vroot/usr/local/share/doc/qemu/tools/_static/plus.png < /vroot/usr/local/share/doc/qemu/tools/_static/pygments.css < /vroot/usr/local/share/doc/qemu/tools/_static/searchtools.js < /vroot/usr/local/share/doc/qemu/tools/_static/underscore-1.3.1.js < /vroot/usr/local/share/doc/qemu/tools/_static/underscore.js < /vroot/usr/local/share/doc/qemu/tools/virtfs-proxy-helper.html < /vroot/usr/local/share/doc/qemu/tools/virtiofsd.html < /vroot/usr/local/share/doc/qemu/user/.buildinfo < /vroot/usr/local/share/doc/qemu/user/genindex.html < /vroot/usr/local/share/doc/qemu/user/index.html < /vroot/usr/local/share/doc/qemu/user/main.html < /vroot/usr/local/share/doc/qemu/user/objects.inv < /vroot/usr/local/share/doc/qemu/user/search.html < /vroot/usr/local/share/doc/qemu/user/searchindex.js < /vroot/usr/local/share/doc/qemu/user/_static/alabaster.css < /vroot/usr/local/share/doc/qemu/user/_static/basic.css < /vroot/usr/local/share/doc/qemu/user/_static/custom.css < /vroot/usr/local/share/doc/qemu/user/_static/doctools.js < /vroot/usr/local/share/doc/qemu/user/_static/documentation_options.js < /vroot/usr/local/share/doc/qemu/user/_static/file.png < /vroot/usr/local/share/doc/qemu/user/_static/jquery-3.2.1.js < /vroot/usr/local/share/doc/qemu/user/_static/jquery.js < /vroot/usr/local/share/doc/qemu/user/_static/language_data.js < /vroot/usr/local/share/doc/qemu/user/_static/minus.png < /vroot/usr/local/share/doc/qemu/user/_static/plus.png < /vroot/usr/local/share/doc/qemu/user/_static/pygments.css < /vroot/usr/local/share/doc/qemu/user/_static/searchtools.js < /vroot/usr/local/share/doc/qemu/user/_static/underscore-1.3.1.js < /vroot/usr/local/share/doc/qemu/user/_static/underscore.js > /vroot/usr/local/share/doc/qemu/specs/specs/acpi_hest_ghes.html > /vroot/usr/local/share/doc/qemu/specs/specs/acpi_hw_reduced_hotplug.html > /vroot/usr/local/share/doc/qemu/specs/specs/.buildinfo > /vroot/usr/local/share/doc/qemu/specs/specs/genindex.html > /vroot/usr/local/share/doc/qemu/specs/specs/index.html > /vroot/usr/local/share/doc/qemu/specs/specs/objects.inv > /vroot/usr/local/share/doc/qemu/specs/specs/ppc-spapr-xive.html > /vroot/usr/local/share/doc/qemu/specs/specs/ppc-xive.html > /vroot/usr/local/share/doc/qemu/specs/specs/search.html > /vroot/usr/local/share/doc/qemu/specs/specs/searchindex.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/specs/specs/_static/basic.css > /vroot/usr/local/share/doc/qemu/specs/specs/_static/custom.css > /vroot/usr/local/share/doc/qemu/specs/specs/_static/doctools.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/file.png > /vroot/usr/local/share/doc/qemu/specs/specs/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/jquery.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/language_data.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/minus.png > /vroot/usr/local/share/doc/qemu/specs/specs/_static/plus.png > /vroot/usr/local/share/doc/qemu/specs/specs/_static/pygments.css > /vroot/usr/local/share/doc/qemu/specs/specs/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/specs/specs/_static/underscore.js > /vroot/usr/local/share/doc/qemu/specs/specs/tpm.html > /vroot/usr/local/share/doc/qemu/system/system/arm/aspeed.html > /vroot/usr/local/share/doc/qemu/system/system/arm/collie.html > /vroot/usr/local/share/doc/qemu/system/system/arm/cpu-features.html > /vroot/usr/local/share/doc/qemu/system/system/arm/digic.html > /vroot/usr/local/share/doc/qemu/system/system/arm/gumstix.html > /vroot/usr/local/share/doc/qemu/system/system/arm/integratorcp.html > /vroot/usr/local/share/doc/qemu/system/system/arm/mps2.html > /vroot/usr/local/share/doc/qemu/system/system/arm/musca.html > /vroot/usr/local/share/doc/qemu/system/system/arm/musicpal.html > /vroot/usr/local/share/doc/qemu/system/system/arm/nseries.html > /vroot/usr/local/share/doc/qemu/system/system/arm/orangepi.html > /vroot/usr/local/share/doc/qemu/system/system/arm/palm.html > /vroot/usr/local/share/doc/qemu/system/system/arm/realview.html > /vroot/usr/local/share/doc/qemu/system/system/arm/stellaris.html > /vroot/usr/local/share/doc/qemu/system/system/arm/sx1.html > /vroot/usr/local/share/doc/qemu/system/system/arm/versatile.html > /vroot/usr/local/share/doc/qemu/system/system/arm/vexpress.html > /vroot/usr/local/share/doc/qemu/system/system/arm/virt.html > /vroot/usr/local/share/doc/qemu/system/system/arm/xscale.html > /vroot/usr/local/share/doc/qemu/system/system/.buildinfo > /vroot/usr/local/share/doc/qemu/system/system/build-platforms.html > /vroot/usr/local/share/doc/qemu/system/system/deprecated.html > /vroot/usr/local/share/doc/qemu/system/system/gdb.html > /vroot/usr/local/share/doc/qemu/system/system/genindex.html > /vroot/usr/local/share/doc/qemu/system/system/images.html > /vroot/usr/local/share/doc/qemu/system/system/index.html > /vroot/usr/local/share/doc/qemu/system/system/invocation.html > /vroot/usr/local/share/doc/qemu/system/system/ivshmem.html > /vroot/usr/local/share/doc/qemu/system/system/keys.html > /vroot/usr/local/share/doc/qemu/system/system/license.html > /vroot/usr/local/share/doc/qemu/system/system/linuxboot.html > /vroot/usr/local/share/doc/qemu/system/system/managed-startup.html > /vroot/usr/local/share/doc/qemu/system/system/monitor.html > /vroot/usr/local/share/doc/qemu/system/system/mux-chardev.html > /vroot/usr/local/share/doc/qemu/system/system/net.html > /vroot/usr/local/share/doc/qemu/system/system/objects.inv > /vroot/usr/local/share/doc/qemu/system/system/qemu-block-drivers.html > /vroot/usr/local/share/doc/qemu/system/system/qemu-cpu-models.html > /vroot/usr/local/share/doc/qemu/system/system/qemu-manpage.html > /vroot/usr/local/share/doc/qemu/system/system/quickstart.html > /vroot/usr/local/share/doc/qemu/system/system/s390x/3270.html > /vroot/usr/local/share/doc/qemu/system/system/s390x/css.html > /vroot/usr/local/share/doc/qemu/system/system/s390x/protvirt.html > /vroot/usr/local/share/doc/qemu/system/system/s390x/vfio-ap.html > /vroot/usr/local/share/doc/qemu/system/system/s390x/vfio-ccw.html > /vroot/usr/local/share/doc/qemu/system/system/search.html > /vroot/usr/local/share/doc/qemu/system/system/searchindex.js > /vroot/usr/local/share/doc/qemu/system/system/security.html > /vroot/usr/local/share/doc/qemu/system/system/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/system/system/_static/basic.css > /vroot/usr/local/share/doc/qemu/system/system/_static/custom.css > /vroot/usr/local/share/doc/qemu/system/system/_static/doctools.js > /vroot/usr/local/share/doc/qemu/system/system/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/system/system/_static/file.png > /vroot/usr/local/share/doc/qemu/system/system/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/system/system/_static/jquery.js > /vroot/usr/local/share/doc/qemu/system/system/_static/language_data.js > /vroot/usr/local/share/doc/qemu/system/system/_static/minus.png > /vroot/usr/local/share/doc/qemu/system/system/_static/plus.png > /vroot/usr/local/share/doc/qemu/system/system/_static/pygments.css > /vroot/usr/local/share/doc/qemu/system/system/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/system/system/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/system/system/_static/underscore.js > /vroot/usr/local/share/doc/qemu/system/system/target-arm.html > /vroot/usr/local/share/doc/qemu/system/system/target-avr.html > /vroot/usr/local/share/doc/qemu/system/system/target-i386.html > /vroot/usr/local/share/doc/qemu/system/system/target-m68k.html > /vroot/usr/local/share/doc/qemu/system/system/target-mips.html > /vroot/usr/local/share/doc/qemu/system/system/target-ppc.html > /vroot/usr/local/share/doc/qemu/system/system/target-rx.html > /vroot/usr/local/share/doc/qemu/system/system/target-s390x.html > /vroot/usr/local/share/doc/qemu/system/system/targets.html > /vroot/usr/local/share/doc/qemu/system/system/target-sparc64.html > /vroot/usr/local/share/doc/qemu/system/system/target-sparc.html > /vroot/usr/local/share/doc/qemu/system/system/target-xtensa.html > /vroot/usr/local/share/doc/qemu/system/system/tls.html > /vroot/usr/local/share/doc/qemu/system/system/usb.html > /vroot/usr/local/share/doc/qemu/system/system/vnc-security.html > /vroot/usr/local/share/doc/qemu/tools/tools/.buildinfo > /vroot/usr/local/share/doc/qemu/tools/tools/genindex.html > /vroot/usr/local/share/doc/qemu/tools/tools/index.html > /vroot/usr/local/share/doc/qemu/tools/tools/objects.inv > /vroot/usr/local/share/doc/qemu/tools/tools/qemu-img.html > /vroot/usr/local/share/doc/qemu/tools/tools/qemu-nbd.html > /vroot/usr/local/share/doc/qemu/tools/tools/qemu-trace-stap.html > /vroot/usr/local/share/doc/qemu/tools/tools/search.html > /vroot/usr/local/share/doc/qemu/tools/tools/searchindex.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/tools/tools/_static/basic.css > /vroot/usr/local/share/doc/qemu/tools/tools/_static/custom.css > /vroot/usr/local/share/doc/qemu/tools/tools/_static/doctools.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/file.png > /vroot/usr/local/share/doc/qemu/tools/tools/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/jquery.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/language_data.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/minus.png > /vroot/usr/local/share/doc/qemu/tools/tools/_static/plus.png > /vroot/usr/local/share/doc/qemu/tools/tools/_static/pygments.css > /vroot/usr/local/share/doc/qemu/tools/tools/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/tools/tools/_static/underscore.js > /vroot/usr/local/share/doc/qemu/tools/tools/virtfs-proxy-helper.html > /vroot/usr/local/share/doc/qemu/tools/tools/virtiofsd.html > /vroot/usr/local/share/doc/qemu/user/user/.buildinfo > /vroot/usr/local/share/doc/qemu/user/user/genindex.html > /vroot/usr/local/share/doc/qemu/user/user/index.html > /vroot/usr/local/share/doc/qemu/user/user/main.html > /vroot/usr/local/share/doc/qemu/user/user/objects.inv > /vroot/usr/local/share/doc/qemu/user/user/search.html > /vroot/usr/local/share/doc/qemu/user/user/searchindex.js > /vroot/usr/local/share/doc/qemu/user/user/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/user/user/_static/basic.css > /vroot/usr/local/share/doc/qemu/user/user/_static/custom.css > /vroot/usr/local/share/doc/qemu/user/user/_static/doctools.js > /vroot/usr/local/share/doc/qemu/user/user/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/user/user/_static/file.png > /vroot/usr/local/share/doc/qemu/user/user/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/user/user/_static/jquery.js > /vroot/usr/local/share/doc/qemu/user/user/_static/language_data.js > /vroot/usr/local/share/doc/qemu/user/user/_static/minus.png > /vroot/usr/local/share/doc/qemu/user/user/_static/plus.png > /vroot/usr/local/share/doc/qemu/user/user/_static/pygments.css > /vroot/usr/local/share/doc/qemu/user/user/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/user/user/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/user/user/_static/underscore.js Regards, Daniel
On 07/08/20 16:02, Peter Maydell wrote: > On Fri, 7 Aug 2020 at 14:55, Markus Armbruster <armbru@redhat.com> wrote: >> I'm notoriously conservative in my choice of tools, and GNU Make is a >> much better tool than some people give it credit for, but I've long felt >> we've pushed it beyond its limits. > > The thing is, it feels somewhat like we're already pushing Meson beyond > *its* limits instead... We totally are pushing it *to* its limits, though I obviously disagree with "beyond". QEMU would certainly be one of the largest projects using Meson. In fact we had to add more than one new feature. One important difference between Make and Meson is that Meson is by design limited in what it can do. The idea (which I think has served them well) is that they want projects to show what they need and work with them on how to build it. So: - with Make you can do everything, it just becomes harder and harder; - with Meson you cannot do everything, plus you're using software that is opinionated and conservative in some respects with respect to its design decisions. In exchange: 1) you can always propose to add features to the upstream project like Marc-André and I did; 2) you don't have to worry about the minute details of everything. So that's what makes Shell+Make and Meson substantially different tools. Stuff like automatically cloning git submodules will never be in Meson, and we can keep Make forever as a small escape hatch for that. However, using Make as a Turing-complete language to build our own DSLs on top of is just a bad idea. Shell+Make can remain simply as a driver for executing commands, which is what Make does best. We also have parts that have effectively separate build systems: I have no plans to convert the TCG tests at all, the firmware could be converted to Meson or Autotools (yes I am serious :)) or left aside, and so on. That said, and going back to pushing Make beyond its limits, I am quite positive that unnest-vars has to go even if the solution has some disadvantages. Meson is one solution, our own home-grown DSL and Makefile generator could be another. However, designing our own build system DSL is not something I want to spend time on; I prefer to improve Meson for every other project using it, it's better for the whole open source development community. The reason why I started thinking about the conversion is that every now and then people entered fights against unnest-vars and I was wondering how those fights would compare to Meson fights. And the result, after about one year of hacking on and off, is that---with one exception---it never felt like I was fighting Meson or the Meson maintainers; any adaptation or concession came naturally, or was even an improvement in retrospect. That one exception, the one thing that disappoints me of the whole conversion, is the trace.h files. The current solution is one of the first parts I did of the conversion and I have never touched it since; I think it can be improved (I can even think of two ways to do it), but I don't really have the time to do it now. But even that bit is just ugly, not unmaintainable, and I really see nothing in the conversion that is a step back for QEMU's long term maintainability and our ability to develop new features. /me gets off the soap box Thanks, Paolo > (it can't do everything we want it to, we've > already had to get at least one new feature added upstream for our benefit, > and in other places we're having to change our existing conventions > to placate Meson). This would be an easier sell if it was "this is all > straightforward and Meson has all the functionality we need". > > I admit that I'm partly feeling a bit more conservative about tooling > right now because we just switched the docs to Sphinx and Sphinx has > turned out to have some annoying problems we didn't foresee. So taking > another tool from the Python universe isn't hugely appealing. > > (This is not a 'nak'; I'm just expressing my unease.) Yes, it's totally understandable.
On 07/08/20 14:20, Cornelia Huck wrote: >> - on an s390x system, it mostly builds, but I end up with a bunch of >> link errors for libblock.fa, where it fails to find various ZSTD_ >> symbols > Still happening after switching to the latest version of your branch. > Fixed thusly: diff --git a/block/meson.build b/block/meson.build index c59e9ebd94..cd3bff5d80 100644 --- a/block/meson.build +++ b/block/meson.build @@ -40,7 +40,7 @@ block_ss.add(files( 'vmdk.c', 'vpc.c', 'write-threshold.c', -)) +), zstd) block_ss.add(when: [zlib, 'CONFIG_QCOW1'], if_true: files('qcow.c')) block_ss.add(when: 'CONFIG_VDI', if_true: files('vdi.c')) diff --git a/configure b/configure index 54c60bc8d6..610801ddaa 100755 --- a/configure +++ b/configure @@ -2623,8 +2623,6 @@ if test "$zstd" != "no" ; then if $pkg_config --atleast-version=$libzstd_minver libzstd ; then zstd_cflags="$($pkg_config --cflags libzstd)" zstd_libs="$($pkg_config --libs libzstd)" - LIBS="$zstd_libs $LIBS" - QEMU_CFLAGS="$QEMU_CFLAGS $zstd_cflags" zstd="yes" else if test "$zstd" = "yes" ; then @@ -7394,6 +7392,8 @@ fi if test "$zstd" = "yes" ; then echo "CONFIG_ZSTD=y" >> $config_host_mak + echo "ZSTD_CFLAGS=$zstd_cflags" >> $config_host_mak + echo "ZSTD_LIBS=$zstd_libs" >> $config_host_mak fi if test "$libiscsi" = "yes" ; then diff --git a/meson.build b/meson.build index 155f7f8065..0323968aec 100644 --- a/meson.build +++ b/meson.build @@ -141,6 +141,11 @@ if 'CONFIG_LIBISCSI' in config_host libiscsi = declare_dependency(compile_args: config_host['LIBISCSI_CFLAGS'].split(), link_args: config_host['LIBISCSI_LIBS'].split()) endif +zstd = not_found +if 'CONFIG_ZSTD' in config_host + zstd = declare_dependency(compile_args: config_host['ZSTD_CFLAGS'].split(), + link_args: config_host['ZSTD_LIBS'].split()) +endif gbm = not_found if 'CONFIG_GBM' in config_host gbm = declare_dependency(compile_args: config_host['GBM_CFLAGS'].split(),
On Fri, 7 Aug 2020 at 16:14, Paolo Bonzini <pbonzini@redhat.com> wrote: > > One important difference between Make and Meson is that Meson is by > design limited in what it can do. The idea (which I think has served > them well) is that they want projects to show what they need and work > with them on how to build it. So: > > - with Make you can do everything, it just becomes harder and harder; > > - with Meson you cannot do everything, plus you're using software that > is opinionated and conservative in some respects with respect to its > design decisions. In exchange: 1) you can always propose to add > features to the upstream project like Marc-André and I did; 2) you don't > have to worry about the minute details of everything. Yeah, this is what I don't like. I don't think this philosophy of tool design is one that works well for us as a large project that prefers to rely on the distro packaged versions of our dependencies and build tools. It would be different if the ecosystem we're in was one where it was really natural to declare versioned dependencies on particular packages or tools and have them automatically pulled in as necessary, perhaps. For instance, I was just glancing through the Meson FAQ, and "tell the compiler not to use RTTI for C++" is apparently something that needed a change to Meson to support, which seems ridiculous. This really feels like we're going to find ourselves in the future boxed into "we're using Meson, but we also need to do X, and Meson's opinion is 'nobody would want X', so we're stuck". This initial attempt at conversion already got stalled for a long time AFAIK because it took a long time to get a feature we wanted into Meson and then for Meson to do a release with the change in it. That seems like a bad sign to me. thanks -- PMM
On 07/08/20 16:29, Daniel P. Berrangé wrote: > New binaries have lost a bunch of libraries they previously linked > to. This isn't neccessarily a bug, if the old make code was incorrectly > adding too many libraries. Yes this is because Meson uses --as-needed. > Comparing 'make install', I see some differences: > > < /vroot/usr/local/bin/elf2dmp > < /vroot/usr/local/bin/qemu-edid > < /vroot/usr/local/bin/qemu-ga > < /vroot/usr/local/bin/qemu-storage-daemon > > /vroot/usr/local/bin/qemu-pr-helper > < /vroot/usr/local/libexec/qemu-pr-helper > < /vroot/usr/local/libexec/vhost-user-gpu > < /vroot/usr/local/libexec/virtfs-proxy-helper > < /vroot/usr/local/libexec/virtiofsd > < /vroot/usr/local/share/locale/sv/LC_MESSAGES/qemu.mo > > Some documentation files have moved - gaining a bogus extra directory > component, and others are missing... I see no missing files after removing the extra directory component. 0a1,38 > /vroot/usr/local/share/doc/qemu/devel/atomics.html > /vroot/usr/local/share/doc/qemu/devel/bitops.html > /vroot/usr/local/share/doc/qemu/devel/.buildinfo > /vroot/usr/local/share/doc/qemu/devel/clocks.html > /vroot/usr/local/share/doc/qemu/devel/decodetree.html > /vroot/usr/local/share/doc/qemu/devel/genindex.html > /vroot/usr/local/share/doc/qemu/devel/index.html > /vroot/usr/local/share/doc/qemu/devel/kconfig.html > /vroot/usr/local/share/doc/qemu/devel/loads-stores.html > /vroot/usr/local/share/doc/qemu/devel/memory.html > /vroot/usr/local/share/doc/qemu/devel/migration.html > /vroot/usr/local/share/doc/qemu/devel/multi-thread-tcg.html > /vroot/usr/local/share/doc/qemu/devel/objects.inv > /vroot/usr/local/share/doc/qemu/devel/reset.html > /vroot/usr/local/share/doc/qemu/devel/s390-dasd-ipl.html > /vroot/usr/local/share/doc/qemu/devel/search.html > /vroot/usr/local/share/doc/qemu/devel/searchindex.js > /vroot/usr/local/share/doc/qemu/devel/secure-coding-practices.html > /vroot/usr/local/share/doc/qemu/devel/stable-process.html > /vroot/usr/local/share/doc/qemu/devel/_static/alabaster.css > /vroot/usr/local/share/doc/qemu/devel/_static/basic.css > /vroot/usr/local/share/doc/qemu/devel/_static/custom.css > /vroot/usr/local/share/doc/qemu/devel/_static/doctools.js > /vroot/usr/local/share/doc/qemu/devel/_static/documentation_options.js > /vroot/usr/local/share/doc/qemu/devel/_static/file.png > /vroot/usr/local/share/doc/qemu/devel/_static/jquery-3.2.1.js > /vroot/usr/local/share/doc/qemu/devel/_static/jquery.js > /vroot/usr/local/share/doc/qemu/devel/_static/language_data.js > /vroot/usr/local/share/doc/qemu/devel/_static/minus.png > /vroot/usr/local/share/doc/qemu/devel/_static/plus.png > /vroot/usr/local/share/doc/qemu/devel/_static/pygments.css > /vroot/usr/local/share/doc/qemu/devel/_static/searchtools.js > /vroot/usr/local/share/doc/qemu/devel/_static/underscore-1.3.1.js > /vroot/usr/local/share/doc/qemu/devel/_static/underscore.js > /vroot/usr/local/share/doc/qemu/devel/tcg.html > /vroot/usr/local/share/doc/qemu/devel/tcg-icount.html > /vroot/usr/local/share/doc/qemu/devel/tcg-plugins.html > /vroot/usr/local/share/doc/qemu/devel/testing.html 10a49,50 > /vroot/usr/local/share/doc/qemu/interop/qemu-ga-ref.info > /vroot/usr/local/share/doc/qemu/interop/qemu-qmp-ref.info I'll stop installing the devel manual and keep the .info file in interop (which hopefully will go away anyway in 5.2). Paolo
On Fri, Aug 07, 2020 at 05:14:06PM +0200, Paolo Bonzini wrote: > Stuff like automatically cloning git submodules will never be in Meson, > and we can keep Make forever as a small escape hatch for that. However, > using Make as a Turing-complete language to build our own DSLs on top of > is just a bad idea. Shell+Make can remain simply as a driver for > executing commands, which is what Make does best. > > We also have parts that have effectively separate build systems: I have > no plans to convert the TCG tests at all, the firmware could be > converted to Meson or Autotools (yes I am serious :)) or left aside, and > so on. Using meson for submodules too is potentially appealing, as you can then take advantage of Meson's subproject support. This makes it easy for distro vendors to turn off building of the bundled pieces in favour of the distro provided equivalent. > That one exception, the one thing that disappoints me of the whole > conversion, is the trace.h files. The current solution is one of the > first parts I did of the conversion and I have never touched it since; I > think it can be improved (I can even think of two ways to do it), but I > don't really have the time to do it now. But even that bit is just > ugly, not unmaintainable, and I really see nothing in the conversion > that is a step back for QEMU's long term maintainability and our ability > to develop new features. I was never entirely happy with the trace.h stuff even in "make". Trying to maintain the "trace.h" name for every generated header was probably a mistake in retrospect. it caused me so much pain trying to get the "make" rules correct so that we resolved the right trace.h in each case. I was deperately trying to avoid updating the #include lines, but I'm not sure it was worth it in the end. Would have been easier to just generate a unique header file name for each dir and update the #includes. Regards, Daniel
On 07/08/20 17:26, Peter Maydell wrote: > For instance, I was just glancing through the Meson FAQ, > and "tell the compiler not to use RTTI for C++" is apparently > something that needed a change to Meson to support, which seems > ridiculous. I am not sure why they singled that out in the FAQ, but there's actually an explanation for requiring a change to Meson: the Meson option takes care of that for both Visual Studio and GCC. If (as we do) you only care about GCC, you can just add -Wno-exceptions just like you'd do with Shell+make. I agree that making it a FAQ is sort of ridiculous. > This really feels like we're going to find ourselves > in the future boxed into "we're using Meson, but we also need > to do X, and Meson's opinion is 'nobody would want X', so we're > stuck". This initial attempt at conversion already got stalled > for a long time AFAIK because it took a long time to get a > feature we wanted into Meson and then for Meson to do a > release with the change in it. That seems like a bad sign to me. I'd say it was mostly because I had other stuff to do. Rebasing to a new release needed me to have the right amount of free time (a lot) at the right point of the release cycle (during freeze). What you refer to is the fact that it took a long time for Meson to declare the "keyval" module stable. That module is what we use to load .mak files from configure and minikconf into Meson, and it was a good thing that it took a long time actually. The initial version was called "kconfig", and the Meson developers were worried about advertising something called "kconfig" when the only user was QEMU and it was not even using kconfig. In the end a user pointed out that QEMU's config-host.mak file is in fact not a valid kconfig files. The Meson developers agreed to keep the code exactly the same, just renaming the module from kconfig to keyval. So I think they made the right call. This was the only feature that took time to stabilize, and I think they made the right call. For what it's worth, the list of things that were contributed is as follows: Completely new functionality: * New "keyval" module * New module "sourceset" to match source file lists against config Extensions to existing constructs: * configure_file(): Allow multiple inputs in command mode * configure_file(): Add depfile argument Interoperability: * Support a NINJA environment variable * mintro: include test protocol in introspection data * Add TAP parser (which we don't use, it was only a bait for the previous change :)) Paolo
On Fri, 7 Aug 2020 17:18:42 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > On 07/08/20 14:20, Cornelia Huck wrote: > >> - on an s390x system, it mostly builds, but I end up with a bunch of > >> link errors for libblock.fa, where it fails to find various ZSTD_ > >> symbols > > Still happening after switching to the latest version of your branch. > > > > Fixed thusly: (...) Thanks, that makes it build now on my LPAR, and it seems to have created a working qemu-system-s390x.
On Mon, 10 Aug 2020 11:58:51 +0200 Cornelia Huck <cohuck@redhat.com> wrote: > On Fri, 7 Aug 2020 17:18:42 +0200 > Paolo Bonzini <pbonzini@redhat.com> wrote: > > > On 07/08/20 14:20, Cornelia Huck wrote: > > >> - on an s390x system, it mostly builds, but I end up with a bunch of > > >> link errors for libblock.fa, where it fails to find various ZSTD_ > > >> symbols > > > Still happening after switching to the latest version of your branch. > > > > > > > Fixed thusly: > > (...) > > Thanks, that makes it build now on my LPAR, and it seems to have > created a working qemu-system-s390x. 'make check' is unhappy, however: Running test qtest-s390x: device-introspect-test missing object type 'virtio-gpu-device' Broken pipe ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) ERROR qtest-s390x: device-introspect-test - too few tests run (expected 6, got 5) Any idea why virtio-gpu is missing? I'd expect it to be included by default.
On 8/7/20 5:58 PM, Daniel P. Berrangé wrote: > On Fri, Aug 07, 2020 at 05:14:06PM +0200, Paolo Bonzini wrote: >> That one exception, the one thing that disappoints me of the whole >> conversion, is the trace.h files. The current solution is one of the >> first parts I did of the conversion and I have never touched it since; I >> think it can be improved (I can even think of two ways to do it), but I >> don't really have the time to do it now. But even that bit is just >> ugly, not unmaintainable, and I really see nothing in the conversion >> that is a step back for QEMU's long term maintainability and our ability >> to develop new features. > > I was never entirely happy with the trace.h stuff even in "make". > Trying to maintain the "trace.h" name for every generated header > was probably a mistake in retrospect. it caused me so much pain > trying to get the "make" rules correct so that we resolved the > right trace.h in each case. I was deperately trying to avoid > updating the #include lines, but I'm not sure it was worth > it in the end. Would have been easier to just generate a unique > header file name for each dir and update the #includes. Never too late. Having unique trace headers would allow us to reuse trace functions in different modules. I.e.: - hexdump() - cases where multi-devices not well split in subsystem parts . xen out of i386 . net could reuse mdio . rocker out of net . can out of net . reuse semihosting traces in target/ - cases with buses where the device is target-specific > > Regards, > Daniel >
On 8/7/20 5:30 PM, Paolo Bonzini wrote: > On 07/08/20 16:29, Daniel P. Berrangé wrote: >> New binaries have lost a bunch of libraries they previously linked >> to. This isn't neccessarily a bug, if the old make code was incorrectly >> adding too many libraries. > > Yes this is because Meson uses --as-needed. Maybe worth a patch at the beginning of the series, before starting the conversion? Phil.
On 10/08/20 12:04, Cornelia Huck wrote: > 'make check' is unhappy, however: > > Running test qtest-s390x: device-introspect-test > missing object type 'virtio-gpu-device' > Broken pipe > ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) > ERROR qtest-s390x: device-introspect-test - too few tests run (expected 6, got 5) It could be an unnecessary dependency on virgl that was detected by the GitLab CI: diff --git a/hw/display/meson.build b/hw/display/meson.build index ffcccc0..fa4f806 100644 --- a/hw/display/meson.build +++ b/hw/display/meson.build @@ -77,7 +77,7 @@ if config_all_devices.has_key('CONFIG_VIRTIO_GPU') #hw_display_modules += [[ 'virtio-gpu', virtio_gpu.sources(), [pixman, virgl], # ['CONFIG_VIRTIO_GPU']]] - softmmu_ss.add_all(when: [pixman, virgl, 'CONFIG_VIRTIO_GPU'], + softmmu_ss.add_all(when: [pixman, 'CONFIG_VIRTIO_GPU'], if_true: virtio_gpu_ss) endif In any case I'll post another version today or tomorrow. (I decided to bite the bullet, include the unit tests conversion and get rid of more Makefile gunk). Paolo
On 10/08/20 12:34, Philippe Mathieu-Daudé wrote: >>> New binaries have lost a bunch of libraries they previously linked >>> to. This isn't neccessarily a bug, if the old make code was incorrectly >>> adding too many libraries. >> Yes this is because Meson uses --as-needed. > Maybe worth a patch at the beginning of the series, before > starting the conversion? Could be, yes. Thanks for the idea! Paolo
On Mon, 10 Aug 2020 13:16:03 +0200 Paolo Bonzini <pbonzini@redhat.com> wrote: > On 10/08/20 12:04, Cornelia Huck wrote: > > 'make check' is unhappy, however: > > > > Running test qtest-s390x: device-introspect-test > > missing object type 'virtio-gpu-device' > > Broken pipe > > ../tests/qtest/libqtest.c:175: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped) > > ERROR qtest-s390x: device-introspect-test - too few tests run (expected 6, got 5) > > It could be an unnecessary dependency on virgl that was detected by the GitLab CI: > > diff --git a/hw/display/meson.build b/hw/display/meson.build > index ffcccc0..fa4f806 100644 > --- a/hw/display/meson.build > +++ b/hw/display/meson.build > @@ -77,7 +77,7 @@ if config_all_devices.has_key('CONFIG_VIRTIO_GPU') > #hw_display_modules += [[ 'virtio-gpu', virtio_gpu.sources(), [pixman, virgl], > # ['CONFIG_VIRTIO_GPU']]] > > - softmmu_ss.add_all(when: [pixman, virgl, 'CONFIG_VIRTIO_GPU'], > + softmmu_ss.add_all(when: [pixman, 'CONFIG_VIRTIO_GPU'], > if_true: virtio_gpu_ss) > endif Yes, that gets me further along. > In any case I'll post another version today or tomorrow. (I decided to bite the > bullet, include the unit tests conversion and get rid of more Makefile gunk). I have another one for you :) Building tests/test-coroutine gives me another link error in libblock.fa(block_qcow2-threads.c.o) (again, some missing zstd symbols; let me know if you need more info.)