Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Andrea Bolognani]

On Wed, 2019-09-18 at 17:46 +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 18, 2019 at 02:55:53PM +0200, Andrea Bolognani wrote:
> > So, to be clear, you're advocating for keeping our list of target
> > platforms unchanged and exempt Meson specifically from the implicit
> > requirement we've had so far, which is that all build dependencies
> > should be installed from distro-provided packages?
> > 
> > I'm not saying that I'm against this, but I think we should at the
> > very least document this prominently, and ideally get an explicit
> > thumbs up from a few downstreams because this could negatively
> > affect their ability to package new libvirt versions.
> 
> Of course the best is if the distro's already ships a standard
> meson that's good enough, if they don't though, they need to
> use a custom meson to build libvirt. So the comparison is
> 
>   - libvirt.tar.gz that contains a copy of meson sources
>   - libvirt.tar.gz and a meson.tar.gz
> 
> Both these cases are functionally the same in what the distro
> ends up building & bundling. So if one causes policy problems
> for the distro, the other will too IMHO.

Sounds reasonable to me, but I would really like to have ACKs from
at least a couple of downstreams and ideally a PoC showing that
doing this doesn't create a massive amount of pain for them. And
documenting it is definitely a must.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Andrea Bolognani]

On Thu, 2019-09-19 at 14:21 +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 19, 2019 at 02:45:53PM +0200, Andrea Bolognani wrote:
> > On Thu, 2019-09-19 at 09:36 +0100, Daniel P. Berrangé wrote:
> > Jumping in a bit late, but why do we care about this distinction in
> > CI at all? In our existing setup, for all projects 'make check' is
> > executed if and only if 'make syntax-check' has succeeded, so the
> > separation is fairly arbitrary and doesn't really buy us anything as
> > far as I can tell.
> 
> I thought we ran the two jobs in parallel but I guess not.

No, we don't :)

> Mostly I'm
> interested in having CI failure mails contain clear error information.
> With the jobs we currently have I find the alerts from the syntax-check
> jobs clearer/easier to consume, than the check jobs. So I'm wary in
> having the syntax-check results just be intermingled with the check job
> results.

I don't think I'm subscribed to the CI mails you talk about, so
generally when I'm investigating a failure I open the full log in the
Jenkins Web UI and make liberal use of Ctrl+F. That seems to work
well enough for me.

If the output of 'ninja test' is too confusing to parse when included
in the body of a mail, then I think the solution is to try and
improve it, because that's what developers will see when they run the
same command in their terminals.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Daniel P . Berrangé]

On Thu, Sep 19, 2019 at 02:45:53PM +0200, Andrea Bolognani wrote:
> On Thu, 2019-09-19 at 09:36 +0100, Daniel P. Berrangé wrote:
> > On Thu, Sep 19, 2019 at 10:20:04AM +0200, Pavel Hrdina wrote:
> > > Another argument from my side was that we require syntax-check and check
> > > to be executed before posting patches to mailing list, having it under
> > > single target would simplify things for new contributors and would align
> > > more with meson community and projects.
> 
> This is pretty nice. I've been guilty of posting patches that passed
> check but not syntax-check in the past O:-) and I know for a fact I'm
> not the only one who's done that ;)
> 
> > > Dan pointed out an issue with our CI that we would loose the separation
> > > in our CI results, which can be solved by using 'suite' labels for tests
> > > that we run, so for syntax-check we can use 'syntax' label and for unit
> > > tests we can use 'unit' label, there can be multiple labels assigned to
> > > each test and to run only a set of tests with a specific label we just
> > > need to run these commands:
> > > 
> > > meson test --suite syntax
> > > meson test --suite unit
> > > 
> > > This way we would still have the separation in our CI and contributors
> > > could easily run `meson test` or `ninja test` to run everything.
> > 
> > Yes, that's a usable approach.
> 
> Jumping in a bit late, but why do we care about this distinction in
> CI at all? In our existing setup, for all projects 'make check' is
> executed if and only if 'make syntax-check' has succeeded, so the
> separation is fairly arbitrary and doesn't really buy us anything as
> far as I can tell.

I thought we ran the two jobs in parallel but I guess not. Mostly I'm
interested in having CI failure mails contain clear error information.
With the jobs we currently have I find the alerts from the syntax-check
jobs clearer/easier to consume, than the check jobs. So I'm wary in
having the syntax-check results just be intermingled with the check job
results.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Andrea Bolognani]

On Thu, 2019-09-19 at 09:36 +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 19, 2019 at 10:20:04AM +0200, Pavel Hrdina wrote:
> > Another argument from my side was that we require syntax-check and check
> > to be executed before posting patches to mailing list, having it under
> > single target would simplify things for new contributors and would align
> > more with meson community and projects.

This is pretty nice. I've been guilty of posting patches that passed
check but not syntax-check in the past O:-) and I know for a fact I'm
not the only one who's done that ;)

> > Dan pointed out an issue with our CI that we would loose the separation
> > in our CI results, which can be solved by using 'suite' labels for tests
> > that we run, so for syntax-check we can use 'syntax' label and for unit
> > tests we can use 'unit' label, there can be multiple labels assigned to
> > each test and to run only a set of tests with a specific label we just
> > need to run these commands:
> > 
> > meson test --suite syntax
> > meson test --suite unit
> > 
> > This way we would still have the separation in our CI and contributors
> > could easily run `meson test` or `ninja test` to run everything.
> 
> Yes, that's a usable approach.

Jumping in a bit late, but why do we care about this distinction in
CI at all? In our existing setup, for all projects 'make check' is
executed if and only if 'make syntax-check' has succeeded, so the
separation is fairly arbitrary and doesn't really buy us anything as
far as I can tell.

>From my point of view, while offering the option above for users can
be nice, once a project switches to Meson and its syntax-check rules
are moved to the test suite, there might as well be a single CI job
which runs 'ninja test' and that's it.

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Daniel P . Berrangé]

On Thu, Sep 19, 2019 at 12:09:23PM +0200, Ján Tomko wrote:
> On Thu, Sep 19, 2019 at 09:36:35AM +0100, Daniel P. Berrangé wrote:
> > On Thu, Sep 19, 2019 at 10:20:04AM +0200, Pavel Hrdina wrote:
> > > On Thu, Sep 19, 2019 at 12:05:23AM +0200, Fabiano Fidêncio wrote:
> > > > On Wed, Sep 18, 2019 at 9:57 PM Ján Tomko  wrote:
> > > > >
> > > > > On Wed, Sep 18, 2019 at 05:40:06PM +0200, Fabiano Fidêncio wrote:
> > > > > >On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio 
> > > > > > wrote:
> > > > > >>
> > > > > >> On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > > > > >> > > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina 
> > > > > >> > >  wrote:
> > > > > >> > This is an intentional change to run syntax-check tests for dist 
> > > > > >> > target
> > > > > >> > as well, but it might be possible to configure it somehow.  
> > > > > >> > Anyway, I
> > > > > >> > would rather prefer to run syntax-check when running ninja dist 
> > > > > >> > than
> > > > > >> > having it as a separate target.
> > > > > >>
> > > > > >> osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses 
> > > > > >> it.
> > > > > >> This is a pattern already being used and here I have a strong
> > > > > >> preference for not changing the pattern if we can easily adapt to 
> > > > > >> it.
> > > > > >
> > > > > >Just for the record, we had a face-to-face discussion about this and
> > > > >
> > > > > Can you record the reasoning as well?
> > > >
> > > > A few topics were brought up:
> > > > - It's closer to what different projects using meson are doing
> > > > (systemd was the example used);
> 
> Not a fan of using systemd as an example O:-)
> 
> > > > - It runs on `ninja dist` without having to run an additional command
> > > > (`ninja syntax-check`);
> > 
> > 
> > I think this is the compelling reason that I didn't understand before.
> > 
> > "ninja dist" is *NOT* the same as "make dist" from autoconf world.
> > It is in fact equivalent to 'make distcheck'. If we have syntx-check
> > as a separate target, then we're loosing a safety check at time of
> > release.
> > 
> 
> I thought that was exactly the point of keeping the target separate -
> not to run the tests meant for patch submissions. For a downstream
> example, I remember us not caring that much for exact spacing or failing
> copyright year check on our RHEL branches.

There is that, but if we look at the kind of things our checks do, a
non-trivial number of checks are verging on code correctness rather
than merely style check. So from that POV, I think running these
checks downstream is actally desirable in general. They can still
opt-out though, if we put the syntax check as  suite test suite
from meson's POV.

> (For example QEMU has these checks separate and only ran on the new
> patch, not the whole codebase)

QEMU is a good example of why that approach is a terrible idea. A
huge portion of QEMU's codebase doesn't comply with the style
checks as no one ever bothers to clean up after new style rules
are added. As a result people submitting patches find themselves
having to fix problems with existing code in order for their
patch to succeed. So you get patches submitted which mix style
and new features in the same patch.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Ján Tomko]

On Thu, Sep 19, 2019 at 09:36:35AM +0100, Daniel P. Berrangé wrote:

On Thu, Sep 19, 2019 at 10:20:04AM +0200, Pavel Hrdina wrote:

On Thu, Sep 19, 2019 at 12:05:23AM +0200, Fabiano Fidêncio wrote:
> On Wed, Sep 18, 2019 at 9:57 PM Ján Tomko  wrote:
> >
> > On Wed, Sep 18, 2019 at 05:40:06PM +0200, Fabiano Fidêncio wrote:
> > >On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio  
wrote:
> > >>
> > >> On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  wrote:
> > >> >
> > >> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > >> > > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  
wrote:
> > >> > This is an intentional change to run syntax-check tests for dist target
> > >> > as well, but it might be possible to configure it somehow.  Anyway, I
> > >> > would rather prefer to run syntax-check when running ninja dist than
> > >> > having it as a separate target.
> > >>
> > >> osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
> > >> This is a pattern already being used and here I have a strong
> > >> preference for not changing the pattern if we can easily adapt to it.
> > >
> > >Just for the record, we had a face-to-face discussion about this and
> >
> > Can you record the reasoning as well?
>
> A few topics were brought up:
> - It's closer to what different projects using meson are doing
> (systemd was the example used);


Not a fan of using systemd as an example O:-)


> - It runs on `ninja dist` without having to run an additional command
> (`ninja syntax-check`);



I think this is the compelling reason that I didn't understand before.

"ninja dist" is *NOT* the same as "make dist" from autoconf world.
It is in fact equivalent to 'make distcheck'. If we have syntx-check
as a separate target, then we're loosing a safety check at time of
release.



I thought that was exactly the point of keeping the target separate -
not to run the tests meant for patch submissions. For a downstream
example, I remember us not caring that much for exact spacing or failing
copyright year check on our RHEL branches.

(For example QEMU has these checks separate and only ran on the new
patch, not the whole codebase)




> - If the test is named 'syntax-check', the test can still be run as
> `meson test syntax-check`;
>
> Everything else is just about personal preference. And talking about
> personal preference, I'd rather keep the syntax-check target, it looks
> cleaner to me ... however, my personal preference is far from counting
> something on "libvirt land" and I'm okay on adapting osinfo related
> projects to whatever is decided here.
>
> There are projects, though, which do not have any tests (gtk-vnc, for
> example) and those will have to add a single test case to run
> syntax-check in order to adapt to this decision. Up to the maintainers
> to decide what to do ... but consistence, IMHO, is important.

A bit more to the reasoning behind dropping syntax-check target.

I was looking at a lot of meson-based projects [1] and none of the
projects that I've checked have syntax-check target and they are using
only the test target.

I was trying to search any usage of syntax-check but it looks like it's
a gnulib specific target, only few projects have this target defined in
Makefile.

Another argument from my side was that we require syntax-check and check
to be executed before posting patches to mailing list, having it under
single target would simplify things for new contributors and would align
more with meson community and projects.



I like this, hopefully we'll get less patches failing syntax-check from
the old contributors as well.

Jano


Dan pointed out an issue with our CI that we would loose the separation
in our CI results, which can be solved by using 'suite' labels for tests
that we run, so for syntax-check we can use 'syntax' label and for unit
tests we can use 'unit' label, there can be multiple labels assigned to
each test and to run only a set of tests with a specific label we just
need to run these commands:

meson test --suite syntax
meson test --suite unit

This way we would still have the separation in our CI and contributors
could easily run `meson test` or `ninja test` to run everything.


Yes, that's a usable approach.

Regards,
Daniel
--
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Daniel P . Berrangé]

On Thu, Sep 19, 2019 at 10:20:04AM +0200, Pavel Hrdina wrote:
> On Thu, Sep 19, 2019 at 12:05:23AM +0200, Fabiano Fidêncio wrote:
> > On Wed, Sep 18, 2019 at 9:57 PM Ján Tomko  wrote:
> > >
> > > On Wed, Sep 18, 2019 at 05:40:06PM +0200, Fabiano Fidêncio wrote:
> > > >On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio  
> > > >wrote:
> > > >>
> > > >> On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  
> > > >> wrote:
> > > >> >
> > > >> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > > >> > > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  
> > > >> > > wrote:
> > > >> > This is an intentional change to run syntax-check tests for dist 
> > > >> > target
> > > >> > as well, but it might be possible to configure it somehow.  Anyway, I
> > > >> > would rather prefer to run syntax-check when running ninja dist than
> > > >> > having it as a separate target.
> > > >>
> > > >> osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
> > > >> This is a pattern already being used and here I have a strong
> > > >> preference for not changing the pattern if we can easily adapt to it.
> > > >
> > > >Just for the record, we had a face-to-face discussion about this and
> > >
> > > Can you record the reasoning as well?
> > 
> > A few topics were brought up:
> > - It's closer to what different projects using meson are doing
> > (systemd was the example used);
> > - It runs on `ninja dist` without having to run an additional command
> > (`ninja syntax-check`);


I think this is the compelling reason that I didn't understand before.

"ninja dist" is *NOT* the same as "make dist" from autoconf world.
It is in fact equivalent to 'make distcheck'. If we have syntx-check
as a separate target, then we're loosing a safety check at time of
release.


> > - If the test is named 'syntax-check', the test can still be run as
> > `meson test syntax-check`;
> > 
> > Everything else is just about personal preference. And talking about
> > personal preference, I'd rather keep the syntax-check target, it looks
> > cleaner to me ... however, my personal preference is far from counting
> > something on "libvirt land" and I'm okay on adapting osinfo related
> > projects to whatever is decided here.
> > 
> > There are projects, though, which do not have any tests (gtk-vnc, for
> > example) and those will have to add a single test case to run
> > syntax-check in order to adapt to this decision. Up to the maintainers
> > to decide what to do ... but consistence, IMHO, is important.
> 
> A bit more to the reasoning behind dropping syntax-check target.
> 
> I was looking at a lot of meson-based projects [1] and none of the
> projects that I've checked have syntax-check target and they are using
> only the test target.
> 
> I was trying to search any usage of syntax-check but it looks like it's
> a gnulib specific target, only few projects have this target defined in
> Makefile.
> 
> Another argument from my side was that we require syntax-check and check
> to be executed before posting patches to mailing list, having it under
> single target would simplify things for new contributors and would align
> more with meson community and projects.
> 
> Dan pointed out an issue with our CI that we would loose the separation
> in our CI results, which can be solved by using 'suite' labels for tests
> that we run, so for syntax-check we can use 'syntax' label and for unit
> tests we can use 'unit' label, there can be multiple labels assigned to
> each test and to run only a set of tests with a specific label we just
> need to run these commands:
> 
> meson test --suite syntax
> meson test --suite unit
>
> This way we would still have the separation in our CI and contributors
> could easily run `meson test` or `ninja test` to run everything.

Yes, that's a usable approach.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Pavel Hrdina]

On Thu, Sep 19, 2019 at 12:05:23AM +0200, Fabiano Fidêncio wrote:
> On Wed, Sep 18, 2019 at 9:57 PM Ján Tomko  wrote:
> >
> > On Wed, Sep 18, 2019 at 05:40:06PM +0200, Fabiano Fidêncio wrote:
> > >On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio  
> > >wrote:
> > >>
> > >> On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  wrote:
> > >> >
> > >> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > >> > > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  
> > >> > > wrote:
> > >> > This is an intentional change to run syntax-check tests for dist target
> > >> > as well, but it might be possible to configure it somehow.  Anyway, I
> > >> > would rather prefer to run syntax-check when running ninja dist than
> > >> > having it as a separate target.
> > >>
> > >> osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
> > >> This is a pattern already being used and here I have a strong
> > >> preference for not changing the pattern if we can easily adapt to it.
> > >
> > >Just for the record, we had a face-to-face discussion about this and
> >
> > Can you record the reasoning as well?
> 
> A few topics were brought up:
> - It's closer to what different projects using meson are doing
> (systemd was the example used);
> - It runs on `ninja dist` without having to run an additional command
> (`ninja syntax-check`);
> - If the test is named 'syntax-check', the test can still be run as
> `meson test syntax-check`;
> 
> Everything else is just about personal preference. And talking about
> personal preference, I'd rather keep the syntax-check target, it looks
> cleaner to me ... however, my personal preference is far from counting
> something on "libvirt land" and I'm okay on adapting osinfo related
> projects to whatever is decided here.
> 
> There are projects, though, which do not have any tests (gtk-vnc, for
> example) and those will have to add a single test case to run
> syntax-check in order to adapt to this decision. Up to the maintainers
> to decide what to do ... but consistence, IMHO, is important.

A bit more to the reasoning behind dropping syntax-check target.

I was looking at a lot of meson-based projects [1] and none of the
projects that I've checked have syntax-check target and they are using
only the test target.

I was trying to search any usage of syntax-check but it looks like it's
a gnulib specific target, only few projects have this target defined in
Makefile.

Another argument from my side was that we require syntax-check and check
to be executed before posting patches to mailing list, having it under
single target would simplify things for new contributors and would align
more with meson community and projects.

Dan pointed out an issue with our CI that we would loose the separation
in our CI results, which can be solved by using 'suite' labels for tests
that we run, so for syntax-check we can use 'syntax' label and for unit
tests we can use 'unit' label, there can be multiple labels assigned to
each test and to run only a set of tests with a specific label we just
need to run these commands:

meson test --suite syntax
meson test --suite unit

This way we would still have the separation in our CI and contributors
could easily run `meson test` or `ninja test` to run everything.

Pavel

[1] 


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Fabiano Fidêncio]

On Wed, Sep 18, 2019 at 9:57 PM Ján Tomko  wrote:
>
> On Wed, Sep 18, 2019 at 05:40:06PM +0200, Fabiano Fidêncio wrote:
> >On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio  wrote:
> >>
> >> On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  wrote:
> >> >
> >> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> >> > > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  
> >> > > wrote:
> >> > This is an intentional change to run syntax-check tests for dist target
> >> > as well, but it might be possible to configure it somehow.  Anyway, I
> >> > would rather prefer to run syntax-check when running ninja dist than
> >> > having it as a separate target.
> >>
> >> osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
> >> This is a pattern already being used and here I have a strong
> >> preference for not changing the pattern if we can easily adapt to it.
> >
> >Just for the record, we had a face-to-face discussion about this and
>
> Can you record the reasoning as well?

A few topics were brought up:
- It's closer to what different projects using meson are doing
(systemd was the example used);
- It runs on `ninja dist` without having to run an additional command
(`ninja syntax-check`);
- If the test is named 'syntax-check', the test can still be run as
`meson test syntax-check`;

Everything else is just about personal preference. And talking about
personal preference, I'd rather keep the syntax-check target, it looks
cleaner to me ... however, my personal preference is far from counting
something on "libvirt land" and I'm okay on adapting osinfo related
projects to whatever is decided here.

There are projects, though, which do not have any tests (gtk-vnc, for
example) and those will have to add a single test case to run
syntax-check in order to adapt to this decision. Up to the maintainers
to decide what to do ... but consistence, IMHO, is important.


>
> Jano
>
> >agreement was to:
> >- Do not introduce the `syntax-check` target for libvirt-dbus;
> >- Patch osinfo-db-tools, (gtk-vnc,)? and libosinfo (depending on when
> >the code will be reviewed / merged) to remove the syntax-check target;
> >- Patch libvirt-jenkins-ci to remove the syntax-check target from the
> >meson jobs;
> >
> >Best Regards,
> >--
> >Fabiano Fidêncio
> >
> >--
> >libvir-list mailing list
> >libvir-list@redhat.com
> >https://www.redhat.com/mailman/listinfo/libvir-list

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Ján Tomko]

On Wed, Sep 18, 2019 at 05:40:06PM +0200, Fabiano Fidêncio wrote:

On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio  wrote:


On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  wrote:
>
> On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  wrote:
> This is an intentional change to run syntax-check tests for dist target
> as well, but it might be possible to configure it somehow.  Anyway, I
> would rather prefer to run syntax-check when running ninja dist than
> having it as a separate target.

osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
This is a pattern already being used and here I have a strong
preference for not changing the pattern if we can easily adapt to it.


Just for the record, we had a face-to-face discussion about this and


Can you record the reasoning as well?

Jano


agreement was to:
- Do not introduce the `syntax-check` target for libvirt-dbus;
- Patch osinfo-db-tools, (gtk-vnc,)? and libosinfo (depending on when
the code will be reviewed / merged) to remove the syntax-check target;
- Patch libvirt-jenkins-ci to remove the syntax-check target from the
meson jobs;

Best Regards,
--
Fabiano Fidêncio

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Daniel P . Berrangé]

On Wed, Sep 18, 2019 at 02:55:53PM +0200, Andrea Bolognani wrote:
> On Wed, 2019-09-18 at 10:39 +0100, Daniel P. Berrangé wrote:
> > We certainly could bundle meson with them, but given that in very
> > short time we're going to have libvirt, libvirt-dbus, osinfo-db-tools,
> > libosinfo, gtk-vnc, spice-gtk all using meson, bundling meson in the
> > individual tarballs feels like a waste of time to me. Distros are
> > better off packaging a newer meson just once. If they can't/won't
> > upgrade their existing meson, then the distros can still bundle
> > a newer meson tarball in the individual source packages they build.
> > 
> > IOW, I think we should just go with whatever is needed to do a good
> > job with meson usage from upstream POV, and let distros jump through
> > whatever hoops they need downstream.
> > 
> > For our CI system, we can just install newer meson ourselves to
> > satisfy the version apps if we want to keep testing on these distros,
> > which I think we should.
> 
> So, to be clear, you're advocating for keeping our list of target
> platforms unchanged and exempt Meson specifically from the implicit
> requirement we've had so far, which is that all build dependencies
> should be installed from distro-provided packages?
> 
> I'm not saying that I'm against this, but I think we should at the
> very least document this prominently, and ideally get an explicit
> thumbs up from a few downstreams because this could negatively
> affect their ability to package new libvirt versions.

Of course the best is if the distro's already ships a standard
meson that's good enough, if they don't though, they need to
use a custom meson to build libvirt. So the comparison is 

  - libvirt.tar.gz that contains a copy of meson sources
  - libvirt.tar.gz and a meson.tar.gz

Both these cases are functionally the same in what the distro
ends up building & bundling. So if one causes policy problems
for the distro, the other will too IMHO. 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Fabiano Fidêncio]

On Wed, Sep 18, 2019 at 1:22 AM Fabiano Fidêncio  wrote:
>
> On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  wrote:
> >
> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  wrote:
> > > >
> > > > Meson build system is simple and quick compared to Autotools and it's
> > > > able to fully replace our Autotools usage.  There are few drawbacks as
> > > > it's a fairly new build system, it requires Python 3.5 and Ninja 1.5.0,
> > > > it's still evolving and the user base is not that large and there were
> > > > some tweaks required to achieve the same functionality.
> > > >
> > > > However, there are benefits, the configure and build time is way shorter
> > > > and build definition files are more readable and easier to maintain.
> > >
> > > Hmm. I really would prefer smaller patches.
> > > - Add meson;
> > > - Drop autotools;
> > > - Change spec files;
> > > - ...
> >
> > I was considering it but to me personally the whole switch in single
> > patch looked fine as there is not that much of a code to add/remove.
> > In addition it's easier to spot if something was not converted, but
> > I can split as I don't care that much.
>
> I don't have any strong opinions here either. So, just leave it as it is.
>
> >
> > > I didn't go through the patch, will do that in the next days ... but a
> > > few things should be considered here:
> > > - meson >= 0.49.0 basically means the project won't be built on Debian
> > > < 10, Ubuntu < 19.04 ... which may be a problem for the project, if
> > > you're following libvirt supported distros;
> >
> > Debian 9 has meson 0.37.1 so yes, this will mean you cannot build
> > upstream libvirt-dbus using distribution packages, but there is
> > Python3.5 so the possible workaround is to install meson using pip.
> >
>
> We don't packages which do not officially come with the distros in
> libvirt-jenkins-ci.
> I sincerely am fine dropping the support for old systems (I just did
> the same for osinfo-db-tools and libosinfo). However, this is a
> libvirt project and I'll leave for libvirt maintainers to decide what
> to do.
>
> > The same applies to Ubuntu and CentOS 7 as well.  There is also a
> > possibility to bundle meson together with our projects but IMHO
> > installing meson using pip in user mode is a good enough workaround
> > if someone is crazy enough to run upstream code on these old
> > distributions.
> >
> > > - please, take a look at the work done on libvirt-jenkins-ci and try
> > > to adapt this one to follow the targets we have there;
> > >   - It'll force the addition of a `ninja syntax-check`, instead of
> > > having the syntax-check as part of the tests;
> >
> > This is an intentional change to run syntax-check tests for dist target
> > as well, but it might be possible to configure it somehow.  Anyway, I
> > would rather prefer to run syntax-check when running ninja dist than
> > having it as a separate target.
>
> osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
> This is a pattern already being used and here I have a strong
> preference for not changing the pattern if we can easily adapt to it.

Just for the record, we had a face-to-face discussion about this and
agreement was to:
- Do not introduce the `syntax-check` target for libvirt-dbus;
- Patch osinfo-db-tools, (gtk-vnc,)? and libosinfo (depending on when
the code will be reviewed / merged) to remove the syntax-check target;
- Patch libvirt-jenkins-ci to remove the syntax-check target from the
meson jobs;

Best Regards,
-- 
Fabiano Fidêncio

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Andrea Bolognani]

On Wed, 2019-09-18 at 10:39 +0100, Daniel P. Berrangé wrote:
> We certainly could bundle meson with them, but given that in very
> short time we're going to have libvirt, libvirt-dbus, osinfo-db-tools,
> libosinfo, gtk-vnc, spice-gtk all using meson, bundling meson in the
> individual tarballs feels like a waste of time to me. Distros are
> better off packaging a newer meson just once. If they can't/won't
> upgrade their existing meson, then the distros can still bundle
> a newer meson tarball in the individual source packages they build.
> 
> IOW, I think we should just go with whatever is needed to do a good
> job with meson usage from upstream POV, and let distros jump through
> whatever hoops they need downstream.
> 
> For our CI system, we can just install newer meson ourselves to
> satisfy the version apps if we want to keep testing on these distros,
> which I think we should.

So, to be clear, you're advocating for keeping our list of target
platforms unchanged and exempt Meson specifically from the implicit
requirement we've had so far, which is that all build dependencies
should be installed from distro-provided packages?

I'm not saying that I'm against this, but I think we should at the
very least document this prominently, and ideally get an explicit
thumbs up from a few downstreams because this could negatively
affect their ability to package new libvirt versions.

> With RHEL-7.7 shipping a python 3 package, we don't have the py2
> problem anymore there.

Not having a suitable Python 3 available on the system would
certainly be a much bigger hurdle than not having Meson, so it's
good that we're now in this position, especially with the Python
clock ticking ever so faster...

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Daniel P . Berrangé]

On Wed, Sep 18, 2019 at 11:30:14AM +0200, Andrea Bolognani wrote:
> On Tue, 2019-09-17 at 20:17 +0200, Pavel Hrdina wrote:
> > On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > > I didn't go through the patch, will do that in the next days ... but a
> > > few things should be considered here:
> > > - meson >= 0.49.0 basically means the project won't be built on Debian
> > > < 10, Ubuntu < 19.04 ... which may be a problem for the project, if
> > > you're following libvirt supported distros;
> > 
> > Debian 9 has meson 0.37.1 so yes, this will mean you cannot build
> > upstream libvirt-dbus using distribution packages, but there is
> > Python3.5 so the possible workaround is to install meson using pip.
> > 
> > The same applies to Ubuntu and CentOS 7 as well.  There is also a
> > possibility to bundle meson together with our projects but IMHO
> > installing meson using pip in user mode is a good enough workaround
> > if someone is crazy enough to run upstream code on these old
> > distributions.
> 
> Yeah, this is definitely a conversation that we need to have.
> 
> Since the idea is to adopt Meson more and more for libvirt-related
> projects, including libvirt itself, we have to find a balance between
> the desire to use relatively recent Meson versions[1] and our current
> platform support policy.
> 
> How much more work would it be to use a baseline Meson release that
> is old enough to be available on all our supported platforms? Can
> that even be done, or there simply is no amount of compatibility code
> that we can use to make it work? How difficult is it to bundle Meson,
> and given that Meson's Apache 2.0 and libvirt's LGPL 2.1+ are not
> compatible can that even be done? I assume a build system such as
> Meson would probably have an exception for users, but I haven't
> checked.

The licensing is a non-issue. Source tar.gz can contain stuff under
as many different licenses as we wish. The license compatibility
requirements affect code that goes into the various programs, libraries
that are built/installed. No meson code gets built into the libvirt
dbus binaries.

We certainly could bundle meson with them, but given that in very
short time we're going to have libvirt, libvirt-dbus, osinfo-db-tools,
libosinfo, gtk-vnc, spice-gtk all using meson, bundling meson in the
individual tarballs feels like a waste of time to me. Distros are
better off packaging a newer meson just once. If they can't/won't
upgrade their existing meson, then the distros can still bundle
a newer meson tarball in the individual source packages they build.

IOW, I think we should just go with whatever is needed to do a good
job with meson usage from upstream POV, and let distros jump through
whatever hoops they need downstream.

For our CI system, we can just install newer meson ourselves to
satisfy the version apps if we want to keep testing on these distros,
which I think we should.

With RHEL-7.7 shipping a python 3 package, we don't have the py2
problem anymore there.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Andrea Bolognani]

On Tue, 2019-09-17 at 20:17 +0200, Pavel Hrdina wrote:
> On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > I didn't go through the patch, will do that in the next days ... but a
> > few things should be considered here:
> > - meson >= 0.49.0 basically means the project won't be built on Debian
> > < 10, Ubuntu < 19.04 ... which may be a problem for the project, if
> > you're following libvirt supported distros;
> 
> Debian 9 has meson 0.37.1 so yes, this will mean you cannot build
> upstream libvirt-dbus using distribution packages, but there is
> Python3.5 so the possible workaround is to install meson using pip.
> 
> The same applies to Ubuntu and CentOS 7 as well.  There is also a
> possibility to bundle meson together with our projects but IMHO
> installing meson using pip in user mode is a good enough workaround
> if someone is crazy enough to run upstream code on these old
> distributions.

Yeah, this is definitely a conversation that we need to have.

Since the idea is to adopt Meson more and more for libvirt-related
projects, including libvirt itself, we have to find a balance between
the desire to use relatively recent Meson versions[1] and our current
platform support policy.

How much more work would it be to use a baseline Meson release that
is old enough to be available on all our supported platforms? Can
that even be done, or there simply is no amount of compatibility code
that we can use to make it work? How difficult is it to bundle Meson,
and given that Meson's Apache 2.0 and libvirt's LGPL 2.1+ are not
compatible can that even be done? I assume a build system such as
Meson would probably have an exception for users, but I haven't
checked.

More in general, as we look at introducing in the libvirt ecosystem
technology that is faster-moving than what we've historically had to
deal with, we might need to change our current stance and just accept
the fact that building libvirt on an older distribution might require
fetching some of the dependencies from side channels such as
third-party repositories or language-specific package managers,
especially when "older distributions" in this case includes the
*latest* Ubuntu LTS release, which is not set to be replaced with a
newer version before at least six months!

Basically the work you're doing in libvirt-dbus[2] will for better or
worse inform the way the entire libvirt ecosystem will deal with the
same challenges a few months down the line, so we should make sure we
don't just hand-wave concerns away because "it's just libvirt-dbus"
but spend some time considering the implications instead.


[1] Meson 0.49.0 was released in December 2018, nine months ago.
[2] Which is awesome, by the way! Thanks for putting the time in :)
-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Fabiano Fidêncio]

On Tue, Sep 17, 2019 at 8:17 PM Pavel Hrdina  wrote:
>
> On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> > On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  wrote:
> > >
> > > Meson build system is simple and quick compared to Autotools and it's
> > > able to fully replace our Autotools usage.  There are few drawbacks as
> > > it's a fairly new build system, it requires Python 3.5 and Ninja 1.5.0,
> > > it's still evolving and the user base is not that large and there were
> > > some tweaks required to achieve the same functionality.
> > >
> > > However, there are benefits, the configure and build time is way shorter
> > > and build definition files are more readable and easier to maintain.
> >
> > Hmm. I really would prefer smaller patches.
> > - Add meson;
> > - Drop autotools;
> > - Change spec files;
> > - ...
>
> I was considering it but to me personally the whole switch in single
> patch looked fine as there is not that much of a code to add/remove.
> In addition it's easier to spot if something was not converted, but
> I can split as I don't care that much.

I don't have any strong opinions here either. So, just leave it as it is.

>
> > I didn't go through the patch, will do that in the next days ... but a
> > few things should be considered here:
> > - meson >= 0.49.0 basically means the project won't be built on Debian
> > < 10, Ubuntu < 19.04 ... which may be a problem for the project, if
> > you're following libvirt supported distros;
>
> Debian 9 has meson 0.37.1 so yes, this will mean you cannot build
> upstream libvirt-dbus using distribution packages, but there is
> Python3.5 so the possible workaround is to install meson using pip.
>

We don't packages which do not officially come with the distros in
libvirt-jenkins-ci.
I sincerely am fine dropping the support for old systems (I just did
the same for osinfo-db-tools and libosinfo). However, this is a
libvirt project and I'll leave for libvirt maintainers to decide what
to do.

> The same applies to Ubuntu and CentOS 7 as well.  There is also a
> possibility to bundle meson together with our projects but IMHO
> installing meson using pip in user mode is a good enough workaround
> if someone is crazy enough to run upstream code on these old
> distributions.
>
> > - please, take a look at the work done on libvirt-jenkins-ci and try
> > to adapt this one to follow the targets we have there;
> >   - It'll force the addition of a `ninja syntax-check`, instead of
> > having the syntax-check as part of the tests;
>
> This is an intentional change to run syntax-check tests for dist target
> as well, but it might be possible to configure it somehow.  Anyway, I
> would rather prefer to run syntax-check when running ninja dist than
> having it as a separate target.

osinfo-db-tools has it, libosinfo has it, libvirt-jenkins-ci uses it.
This is a pattern already being used and here I have a strong
preference for not changing the pattern if we can easily adapt to it.

>
> >
> > Again, I'll carefully go through this patch in the next days.
>
> Thanks, I'll fix the issues pointed out by Jano and send a link to
> repository with the changes.

Cool, looking forward for the link.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Pavel Hrdina]

On Tue, Sep 17, 2019 at 06:53:30PM +0200, Fabiano Fidêncio wrote:
> On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  wrote:
> >
> > Meson build system is simple and quick compared to Autotools and it's
> > able to fully replace our Autotools usage.  There are few drawbacks as
> > it's a fairly new build system, it requires Python 3.5 and Ninja 1.5.0,
> > it's still evolving and the user base is not that large and there were
> > some tweaks required to achieve the same functionality.
> >
> > However, there are benefits, the configure and build time is way shorter
> > and build definition files are more readable and easier to maintain.
> 
> Hmm. I really would prefer smaller patches.
> - Add meson;
> - Drop autotools;
> - Change spec files;
> - ...

I was considering it but to me personally the whole switch in single
patch looked fine as there is not that much of a code to add/remove.
In addition it's easier to spot if something was not converted, but
I can split as I don't care that much.

> I didn't go through the patch, will do that in the next days ... but a
> few things should be considered here:
> - meson >= 0.49.0 basically means the project won't be built on Debian
> < 10, Ubuntu < 19.04 ... which may be a problem for the project, if
> you're following libvirt supported distros;

Debian 9 has meson 0.37.1 so yes, this will mean you cannot build
upstream libvirt-dbus using distribution packages, but there is
Python3.5 so the possible workaround is to install meson using pip.

The same applies to Ubuntu and CentOS 7 as well.  There is also a
possibility to bundle meson together with our projects but IMHO
installing meson using pip in user mode is a good enough workaround
if someone is crazy enough to run upstream code on these old
distributions.

> - please, take a look at the work done on libvirt-jenkins-ci and try
> to adapt this one to follow the targets we have there;
>   - It'll force the addition of a `ninja syntax-check`, instead of
> having the syntax-check as part of the tests;

This is an intentional change to run syntax-check tests for dist target
as well, but it might be possible to configure it somehow.  Anyway, I
would rather prefer to run syntax-check when running ninja dist than
having it as a separate target.

> 
> Again, I'll carefully go through this patch in the next days.

Thanks, I'll fix the issues pointed out by Jano and send a link to
repository with the changes.

Pavel


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Pavel Hrdina]

On Tue, Sep 17, 2019 at 06:39:17PM +0200, Ján Tomko wrote:
> On Tue, Sep 17, 2019 at 05:20:43PM +0200, Pavel Hrdina wrote:
> > Meson build system is simple and quick compared to Autotools and it's
> > able to fully replace our Autotools usage.  There are few drawbacks as
> > it's a fairly new build system, it requires Python 3.5 and Ninja 1.5.0,
> > it's still evolving and the user base is not that large and there were
> > some tweaks required to achieve the same functionality.
> > 
> > However, there are benefits, the configure and build time is way shorter
> 
> Neat, despite the colors
> 
> > and build definition files are more readable and easier to maintain.
> > 
> > Signed-off-by: Pavel Hrdina 
> > ---
> > .gitignore  |   1 +
> > AUTHORS.in  |   2 +-
> > HACKING.md  |  16 +--
> > Makefile.am |  51 ---
> > README.md   |  12 +-
> > autogen.sh  |  52 ---
> > configure.ac|  87 
> > data/Makefile.am|  83 ---
> > data/meson.build|  15 ++
> > data/session/meson.build|   6 +
> > data/system/meson.build |  18 +++
> > docs/Makefile.am|  21 ---
> > docs/meson.build|   8 ++
> > libvirt-dbus.spec.in|   8 +-
> > m4/manywarnings.m4  | 276 
> > m4/virt-arg.m4  | 154 
> > m4/virt-compile-pie.m4  |  35 -
> > m4/virt-compile-warnings.m4 | 203 --
> > m4/virt-linker-relro.m4 |  35 -
> > m4/warnings.m4  |  79 ---
> > meson.build | 271 +++
> > meson_options.txt   |   6 +
> > run.in  |   4 +-
> > src/Makefile.am |  66 -
> > src/domain.c|   2 +-
> > src/meson.build |  54 +++
> > tests/Makefile.am   |  57 
> > tests/meson.build   |  49 +++
> > tools/gen-authors.sh|   8 ++
> > 29 files changed, 454 insertions(+), 1225 deletions(-)
> > delete mode 100644 Makefile.am
> > delete mode 100755 autogen.sh
> > delete mode 100644 configure.ac
> > delete mode 100644 data/Makefile.am
> > create mode 100644 data/meson.build
> > create mode 100644 data/session/meson.build
> > create mode 100644 data/system/meson.build
> > delete mode 100644 docs/Makefile.am
> > create mode 100644 docs/meson.build
> > delete mode 100644 m4/manywarnings.m4
> > delete mode 100644 m4/virt-arg.m4
> > delete mode 100644 m4/virt-compile-pie.m4
> > delete mode 100644 m4/virt-compile-warnings.m4
> > delete mode 100644 m4/virt-linker-relro.m4
> > delete mode 100644 m4/warnings.m4
> > create mode 100644 meson.build
> > create mode 100644 meson_options.txt
> > mode change 100644 => 100755 run.in
> > delete mode 100644 src/Makefile.am
> > create mode 100644 src/meson.build
> > delete mode 100644 tests/Makefile.am
> > create mode 100644 tests/meson.build
> > create mode 100755 tools/gen-authors.sh
> > 
> > -dist-hook: gen-AUTHORS
> > -
> > -# Generate the AUTHORS file (with all entries since the switch to git)
> > -# and insert it into the directory we're about to use to create a tarball.
> > -.PHONY: gen-AUTHORS
> > -gen-AUTHORS:
> > -   $(AM_V_GEN)\
> > -   if test -d $(srcdir)/.git; then \
> > - ( \
> > -   cd $(srcdir) && \
> > -   git log --pretty=format:'%aN <%aE>' | sort -u \
> > - ) > all.list && \
> > - sort -u $(srcdir)/AUTHORS.in > maint.list && \
> > - comm -23 all.list maint.list > contrib.list && \
> 
> This filtering is not present in the meson version, but I can live with
> that "regression"

I can fix that, will look into it.

> > - contrib="`cat contrib.list`" && \
> > - perl -p -e "s/#contributorslist#// and print '$$contrib'" \
> > -   < $(srcdir)/AUTHORS.in > $(distdir)/AUTHORS-tmp && \
> > - mv -f $(distdir)/AUTHORS-tmp $(distdir)/AUTHORS && \
> > - rm -f all.list maint.list contrib.list; \
> > -   fi
> > -
> 
> 
> > diff --git a/configure.ac b/configure.ac
> > deleted file mode 100644
> > index 24ebb26..000
> > --- a/configure.ac
> > +++ /dev/null
> > -LIBVIRT_DBUS_MAJOR_VERSION=`echo $VERSION | awk -F. '{print $1}'`
> > -LIBVIRT_DBUS_MINOR_VERSION=`echo $VERSION | awk -F. '{print $2}'`
> > -LIBVIRT_DBUS_MICRO_VERSION=`echo $VERSION | awk -F. '{print $3}'`
> > -LIBVIRT_DBUS_VERSION=$LIBVIRT_DBUS_MAJOR_VERSION.$LIBVIRT_DBUS_MINOR_VERSION.$LIBVIRT_DBUS_MICRO_VERSION$LIBVIRT_DBUS_MICRO_VERSION_SUFFIX
> > -LIBVIRT_DBUS_VERSION_NUMBER=`expr $LIBVIRT_DBUS_MAJOR_VERSION \* 100 + 
> > $LIBVIRT_dbus_MINOR_VERSION \* 1000 + $LIBVIRT_DBUS_MICRO_VERSION`
> > -
> > -AC_SUBST([LIBVIRT_DBUS_MAJOR_VERSION])
> > -AC_SUBST([LIBVIRT_DBUS_MINOR_VERSION])
> > -AC_SUBST([LIBVIRT_DBUS_MICRO_VERSION])
> > -AC_SUBST([LIBVIRT_DBUS_VERSION])
> > -AC_SUBST([LIBVIRT_DBUS_VERSION_INFO])
> > 

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Fabiano Fidêncio]

On Tue, Sep 17, 2019 at 5:22 PM Pavel Hrdina  wrote:
>
> Meson build system is simple and quick compared to Autotools and it's
> able to fully replace our Autotools usage.  There are few drawbacks as
> it's a fairly new build system, it requires Python 3.5 and Ninja 1.5.0,
> it's still evolving and the user base is not that large and there were
> some tweaks required to achieve the same functionality.
>
> However, there are benefits, the configure and build time is way shorter
> and build definition files are more readable and easier to maintain.

Hmm. I really would prefer smaller patches.
- Add meson;
- Drop autotools;
- Change spec files;
- ...

I didn't go through the patch, will do that in the next days ... but a
few things should be considered here:
- meson >= 0.49.0 basically means the project won't be built on Debian
< 10, Ubuntu < 19.04 ... which may be a problem for the project, if
you're following libvirt supported distros;
- please, take a look at the work done on libvirt-jenkins-ci and try
to adapt this one to follow the targets we have there;
  - It'll force the addition of a `ninja syntax-check`, instead of
having the syntax-check as part of the tests;

Again, I'll carefully go through this patch in the next days.

Best Regards,
-- 
Fabiano Fidêncio

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [dbus PATCH] build: convert to Meson/Ninja build system

[Ján Tomko]

On Tue, Sep 17, 2019 at 05:20:43PM +0200, Pavel Hrdina wrote:

Meson build system is simple and quick compared to Autotools and it's
able to fully replace our Autotools usage.  There are few drawbacks as
it's a fairly new build system, it requires Python 3.5 and Ninja 1.5.0,
it's still evolving and the user base is not that large and there were
some tweaks required to achieve the same functionality.

However, there are benefits, the configure and build time is way shorter


Neat, despite the colors


and build definition files are more readable and easier to maintain.

Signed-off-by: Pavel Hrdina 
---
.gitignore  |   1 +
AUTHORS.in  |   2 +-
HACKING.md  |  16 +--
Makefile.am |  51 ---
README.md   |  12 +-
autogen.sh  |  52 ---
configure.ac|  87 
data/Makefile.am|  83 ---
data/meson.build|  15 ++
data/session/meson.build|   6 +
data/system/meson.build |  18 +++
docs/Makefile.am|  21 ---
docs/meson.build|   8 ++
libvirt-dbus.spec.in|   8 +-
m4/manywarnings.m4  | 276 
m4/virt-arg.m4  | 154 
m4/virt-compile-pie.m4  |  35 -
m4/virt-compile-warnings.m4 | 203 --
m4/virt-linker-relro.m4 |  35 -
m4/warnings.m4  |  79 ---
meson.build | 271 +++
meson_options.txt   |   6 +
run.in  |   4 +-
src/Makefile.am |  66 -
src/domain.c|   2 +-
src/meson.build |  54 +++
tests/Makefile.am   |  57 
tests/meson.build   |  49 +++
tools/gen-authors.sh|   8 ++
29 files changed, 454 insertions(+), 1225 deletions(-)
delete mode 100644 Makefile.am
delete mode 100755 autogen.sh
delete mode 100644 configure.ac
delete mode 100644 data/Makefile.am
create mode 100644 data/meson.build
create mode 100644 data/session/meson.build
create mode 100644 data/system/meson.build
delete mode 100644 docs/Makefile.am
create mode 100644 docs/meson.build
delete mode 100644 m4/manywarnings.m4
delete mode 100644 m4/virt-arg.m4
delete mode 100644 m4/virt-compile-pie.m4
delete mode 100644 m4/virt-compile-warnings.m4
delete mode 100644 m4/virt-linker-relro.m4
delete mode 100644 m4/warnings.m4
create mode 100644 meson.build
create mode 100644 meson_options.txt
mode change 100644 => 100755 run.in
delete mode 100644 src/Makefile.am
create mode 100644 src/meson.build
delete mode 100644 tests/Makefile.am
create mode 100644 tests/meson.build
create mode 100755 tools/gen-authors.sh

-dist-hook: gen-AUTHORS
-
-# Generate the AUTHORS file (with all entries since the switch to git)
-# and insert it into the directory we're about to use to create a tarball.
-.PHONY: gen-AUTHORS
-gen-AUTHORS:
-   $(AM_V_GEN)\
-   if test -d $(srcdir)/.git; then \
- ( \
-   cd $(srcdir) && \
-   git log --pretty=format:'%aN <%aE>' | sort -u \
- ) > all.list && \
- sort -u $(srcdir)/AUTHORS.in > maint.list && \
- comm -23 all.list maint.list > contrib.list && \


This filtering is not present in the meson version, but I can live with
that "regression"


- contrib="`cat contrib.list`" && \
- perl -p -e "s/#contributorslist#// and print '$$contrib'" \
-   < $(srcdir)/AUTHORS.in > $(distdir)/AUTHORS-tmp && \
- mv -f $(distdir)/AUTHORS-tmp $(distdir)/AUTHORS && \
- rm -f all.list maint.list contrib.list; \
-   fi
-




diff --git a/configure.ac b/configure.ac
deleted file mode 100644
index 24ebb26..000
--- a/configure.ac
+++ /dev/null
-LIBVIRT_DBUS_MAJOR_VERSION=`echo $VERSION | awk -F. '{print $1}'`
-LIBVIRT_DBUS_MINOR_VERSION=`echo $VERSION | awk -F. '{print $2}'`
-LIBVIRT_DBUS_MICRO_VERSION=`echo $VERSION | awk -F. '{print $3}'`
-LIBVIRT_DBUS_VERSION=$LIBVIRT_DBUS_MAJOR_VERSION.$LIBVIRT_DBUS_MINOR_VERSION.$LIBVIRT_DBUS_MICRO_VERSION$LIBVIRT_DBUS_MICRO_VERSION_SUFFIX
-LIBVIRT_DBUS_VERSION_NUMBER=`expr $LIBVIRT_DBUS_MAJOR_VERSION \* 100 + 
$LIBVIRT_dbus_MINOR_VERSION \* 1000 + $LIBVIRT_DBUS_MICRO_VERSION`
-
-AC_SUBST([LIBVIRT_DBUS_MAJOR_VERSION])
-AC_SUBST([LIBVIRT_DBUS_MINOR_VERSION])
-AC_SUBST([LIBVIRT_DBUS_MICRO_VERSION])
-AC_SUBST([LIBVIRT_DBUS_VERSION])
-AC_SUBST([LIBVIRT_DBUS_VERSION_INFO])
-AC_SUBST([LIBVIRT_DBUS_VERSION_NUMBER])
-


We lose these, but they were unusued.


-AC_PROG_CC
-AC_PROG_MKDIR_P
-AM_PROG_CC_C_O
-AC_PROG_CC_STDC
-AC_PROG_LIBTOOL
-AC_PATH_PROGS([FLAKE8], [flake8 flake8-3.6])
-
diff --git a/meson.build b/meson.build
new file mode 100644
index 000..9cc4417
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,271 @@
+project(
+'libvirt-dbus', 'c',
+version:'1.4.0',
+license: 'LGPLv2+',
+meson_version: '>= 0.49.0',
+default_options: [
+