[Buildroot] ninja/python-meson packages

[Buildroot] ninja/python-meson packages

[Cédric Marie]

Hi,

Regarding python-meson package that was proposed here:
http://lists.busybox.net/pipermail/buildroot/2016-June/163437.html

>> However, I could provide a real package infrastructure named 
>> "meson-package",
>> but as stated in the discussion about adding support for Cargo (the 
>> Rust
>> package manager), to provide such infrastructure, at least one package 
>> using
>> it should also be provided (it is sensible to have a working example 
>> of
>> the infrastructure).

> I would not say one, but at least 4-5 packages, with a pretty good
> confidence that more packages would be added later on.

Gstreamer has added Meson as an alternative build system (to Autotools) 
since August 2016:

https://cgit.freedesktop.org/gstreamer/gstreamer/commit/meson.build?id=b2f9808722a0254acba17ef98a612a2792184e12

And I suppose that other projects are likely to switch... The decrease 
of build time is really interesting compared to Autotools, CMake, and 
even CMake with ninja backend.

By the way, is there any chance to give CMake package the possibility to 
use ninja backend? (which will also decrease build time of CMake 
packages)
I have local modifications of my buildroot tree that achieve that, but 
I'm not sure about the right way to propose it. I have added an option 
(BR2_PACKAGE_CMAKE_NINJA) but it appears in target packages > 
Development tools, while it is not intended for the target. Would it be 
a better idea to create a specific package infra (pkg-cmake-ninja.mk)?
Or maybe it is just not useful... I don't know whether the user really 
needs to choose between two different backends, while the result is 
supposed to be the same (only the build time will differ).

NB: Comparison of build time can be found here:
https://github.com/mesonbuild/meson/wiki/Simple%20comparison

-- 
C?dric

[Buildroot] ninja/python-meson packages

[Thomas Petazzoni]

Hello,

On Wed, 09 Nov 2016 16:26:38 +0100, C?dric Marie wrote:

> > I would not say one, but at least 4-5 packages, with a pretty good
> > confidence that more packages would be added later on.  
> 
> Gstreamer has added Meson as an alternative build system (to Autotools) 
> since August 2016:
> 
> https://cgit.freedesktop.org/gstreamer/gstreamer/commit/meson.build?id=b2f9808722a0254acba17ef98a612a2792184e12
> 
> And I suppose that other projects are likely to switch... The decrease 
> of build time is really interesting compared to Autotools, CMake, and 
> even CMake with ninja backend.

We are definitely fine with supporting the meson build system in
Buildroot. The only reason we didn't merge the patches that were
proposed is because no package was using them. As soon as we have one
package using this build system in Buildroot, we will of course happily
merge patches adding support for it.

> By the way, is there any chance to give CMake package the possibility to 
> use ninja backend? (which will also decrease build time of CMake 
> packages)

I don't know exactly what is involved in such a change, but in
principle, I don't see why we wouldn't accept that.

> I have local modifications of my buildroot tree that achieve that, but 
> I'm not sure about the right way to propose it. I have added an option 
> (BR2_PACKAGE_CMAKE_NINJA) but it appears in target packages > 
> Development tools, while it is not intended for the target. Would it be 
> a better idea to create a specific package infra (pkg-cmake-ninja.mk)?

Can each and every CMake package use Ninja as a backend?

At first, it should probably just be an option under "Build options",
that affects the behavior of pkg-cmake. Once we get a better
understanding of what it means to use Ninja in terms of additional
dependencies to build, and number of CMake packages that work/don't
work with it, then we can decide what to do.

How does that sound?

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] ninja/python-meson packages

[Cédric Marie]

Hi,

+ Eric Le Bihan who first proposed ninja/meson support.

Le 09/11/2016 ? 21:28, Thomas Petazzoni a ?crit :
> We are definitely fine with supporting the meson build system in
> Buildroot. The only reason we didn't merge the patches that were
> proposed is because no package was using them. As soon as we have one
> package using this build system in Buildroot, we will of course happily
> merge patches adding support for it.

The current gstreamer1 version in Buildroot is 1.8.3.
The support for meson was added in 1.9.2. So upgrading gstreamer1 is 
certainly necessary before merging Meson support.


>> By the way, is there any chance to give CMake package the possibility to
>> use ninja backend? (which will also decrease build time of CMake
>> packages)
>
> I don't know exactly what is involved in such a change, but in
> principle, I don't see why we wouldn't accept that.

Roughly, add dependency on ninja, add an option in cmake configure step 
(-G ninja) and use ninja instead of make in build and install commands.


> At first, it should probably just be an option under "Build options",
> that affects the behavior of pkg-cmake. Once we get a better
> understanding of what it means to use Ninja in terms of additional
> dependencies to build, and number of CMake packages that work/don't
> work with it, then we can decide what to do.
>
> How does that sound?

That sounds good to me :)

An option in "Build options" is definitely more appropriate. In the 
first place I had just added it in package/cmake/Config.in - which made 
it appear in target development tools.
Then I will check with several existing CMake packages in buildroot.

Regarding Meson integration, I think that Eric - if he's still 
interested in working on that - is the right person. I understand that 
his patches didn't provide pkg-meson.mk yet, but he proposed to do so. 
Am I right?


-- 
C?dric

[Buildroot] ninja/python-meson packages

[Thomas Petazzoni]

Hello,

On Wed, 9 Nov 2016 23:01:12 +0100, C?dric Marie wrote:

> Le 09/11/2016 ? 21:28, Thomas Petazzoni a ?crit :
> > We are definitely fine with supporting the meson build system in
> > Buildroot. The only reason we didn't merge the patches that were
> > proposed is because no package was using them. As soon as we have one
> > package using this build system in Buildroot, we will of course happily
> > merge patches adding support for it.  
> 
> The current gstreamer1 version in Buildroot is 1.8.3.
> The support for meson was added in 1.9.2. So upgrading gstreamer1 is 
> certainly necessary before merging Meson support.

OK. However, isn't 1.9.x considered a "development" branch from the
point of view of GStreamer? At least for Glib/Gtk, the releases with
an odd are development ones if I remember correctly.

> >> By the way, is there any chance to give CMake package the possibility to
> >> use ninja backend? (which will also decrease build time of CMake
> >> packages)  
> >
> > I don't know exactly what is involved in such a change, but in
> > principle, I don't see why we wouldn't accept that.  
> 
> Roughly, add dependency on ninja, add an option in cmake configure step 
> (-G ninja) and use ninja instead of make in build and install commands.

OK, sounds good. We definitely want to make this optional for now I
believe.

> An option in "Build options" is definitely more appropriate. In the 
> first place I had just added it in package/cmake/Config.in - which made 
> it appear in target development tools.
> Then I will check with several existing CMake packages in buildroot.

Good;

> Regarding Meson integration, I think that Eric - if he's still 
> interested in working on that - is the right person. I understand that 
> his patches didn't provide pkg-meson.mk yet, but he proposed to do so. 
> Am I right?

Having an infrastructure is not necessarily useful at the beginning. If
we have only one or two packages using meson, and its usage is pretty
simple, we can just as well do it directly in the packages themselves.
Like we're doing for qmake based packages today for example.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] ninja/python-meson packages

[Baruch Siach]

Hi C?dric,

On Wed, Nov 09, 2016 at 11:01:12PM +0100, C?dric Marie wrote:
> Roughly, add dependency on ninja, add an option in cmake configure step (-G
> ninja) and use ninja instead of make in build and install commands.

Does that mean that we won't be able to use the host distro installed cmake? 
Not so good in terms of build time. I guess it offsets most of the build time 
gain in moving to ninja, if not more.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

[Buildroot] ninja/python-meson packages

[Thomas Petazzoni]

Hello,

On Thu, 10 Nov 2016 06:42:45 +0200, Baruch Siach wrote:

> On Wed, Nov 09, 2016 at 11:01:12PM +0100, C?dric Marie wrote:
> > Roughly, add dependency on ninja, add an option in cmake configure step (-G
> > ninja) and use ninja instead of make in build and install commands.  
> 
> Does that mean that we won't be able to use the host distro installed cmake? 
> Not so good in terms of build time. I guess it offsets most of the build time 
> gain in moving to ninja, if not more.

This is one of the reasons why I want to have this as an option, at
least initially. We clearly want to keep the nice benefit of using the
system-provided CMake.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] ninja/python-meson packages

[Cédric Marie]

Hi,

Le 2016-11-10 09:18, Thomas Petazzoni a ?crit?:
> On Thu, 10 Nov 2016 06:42:45 +0200, Baruch Siach wrote:
>> Does that mean that we won't be able to use the host distro installed 
>> cmake?
>> Not so good in terms of build time. I guess it offsets most of the 
>> build time
>> gain in moving to ninja, if not more.
> 
> This is one of the reasons why I want to have this as an option, at
> least initially. We clearly want to keep the nice benefit of using the
> system-provided CMake.

I was not aware of the new possibility to use cmake from the host 
(support/dependencies/check-host-cmake.mk). But it is not a problem.

There is a misunderstanding, I need to clarify:
I'm not changing anything in cmake package, I'm only modifying 
pkg-cmake.mk.
CMake (either from your host, or host-cmake from buildroot) has support 
for both make and ninja backend, it is not an option at compilation 
time.
It is a "configure option" to set in pkg-cmake.mk ($(2)_CONF_OPTS += -G 
Ninja), in the configure step of each package based on cmake infra.

Yet you're right as far as "make" is concerned.
Buildroot and CMake use "make" from your host distro. If we switch to 
ninja, it implies that an extra package needs to be built: host-ninja.
So the benefit of ninja is only:
- if you have several packages using CMake (I can't say how many are 
necessary to cancel out host-ninja build time...)
- if you rebuild CMake packages regularly - in development mode, which 
is not what buildroot is designed for, in the first place.
- if another package uses meson: host-ninja is required anyway... (but 
this is the future ;))

-- 
C?dric

[Buildroot] ninja/python-meson packages

[Thijs Vermeir]

Hi,

On Wed, Nov 9, 2016 at 11:13 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 9 Nov 2016 23:01:12 +0100, C?dric Marie wrote:
>
>> Le 09/11/2016 ? 21:28, Thomas Petazzoni a ?crit :
>> > We are definitely fine with supporting the meson build system in
>> > Buildroot. The only reason we didn't merge the patches that were
>> > proposed is because no package was using them. As soon as we have one
>> > package using this build system in Buildroot, we will of course happily
>> > merge patches adding support for it.
>>
>> The current gstreamer1 version in Buildroot is 1.8.3.
>> The support for meson was added in 1.9.2. So upgrading gstreamer1 is
>> certainly necessary before merging Meson support.
>
> OK. However, isn't 1.9.x considered a "development" branch from the
> point of view of GStreamer? At least for Glib/Gtk, the releases with
> an odd are development ones if I remember correctly.

Yes, that is correct. GStreamer 1.10.0 is now the latest stable
release. Note that the
support for the meson build system is only experimental and not on par
with the autotools
based build system.

Gr,
Thijs

[Buildroot] ninja/python-meson packages

[Cédric Marie]

Hi,

Le 10/11/2016 ? 11:28, Thijs Vermeir a ?crit :
> Yes, that is correct. GStreamer 1.10.0 is now the latest stable
> release. Note that the
> support for the meson build system is only experimental and not on par
> with the autotools based build system.

You're right, it may not be a good idea to switch gstreamer to Meson too 
soon.
I also wanted to point out that Meson was used by significant projects, 
and likely to become more and more popular.

-- 
C?dric

[Buildroot] ninja/python-meson packages

[Arnout Vandecappelle]

On 10-11-16 11:28, Thijs Vermeir wrote:
> Hi,
> 
> On Wed, Nov 9, 2016 at 11:13 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> On Wed, 9 Nov 2016 23:01:12 +0100, C?dric Marie wrote:
>>
>>> Le 09/11/2016 ? 21:28, Thomas Petazzoni a ?crit :
>>>> We are definitely fine with supporting the meson build system in
>>>> Buildroot. The only reason we didn't merge the patches that were
>>>> proposed is because no package was using them. As soon as we have one
>>>> package using this build system in Buildroot, we will of course happily
>>>> merge patches adding support for it.
>>>
>>> The current gstreamer1 version in Buildroot is 1.8.3.
>>> The support for meson was added in 1.9.2. So upgrading gstreamer1 is
>>> certainly necessary before merging Meson support.
>>
>> OK. However, isn't 1.9.x considered a "development" branch from the
>> point of view of GStreamer? At least for Glib/Gtk, the releases with
>> an odd are development ones if I remember correctly.
> 
> Yes, that is correct. GStreamer 1.10.0 is now the latest stable
> release. Note that the
> support for the meson build system is only experimental and not on par
> with the autotools
> based build system.

 Perhaps then it would be good for the GStreamer project if the meson build
system would be (build)-tested by the buildroot autobuild infrastructure, no?

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] ninja/python-meson packages

[Fatih Aşıcı]

On Wednesday, November 9, 2016 6:26:38 PM +03, C?dric Marie wrote:
> Hi,
>
> Regarding python-meson package that was proposed here:
> http://lists.busybox.net/pipermail/buildroot/2016-June/163437.html
>
>>> However, I could provide a real package infrastructure named 
>>> "meson-package",
>>> but as stated in the discussion about adding support for Cargo (the Rust
>>> package manager), to provide such infrastructure, at least 
>>> one package using
>>> it should also be provided (it is sensible to have a working example of
>>> the infrastructure).
>
>> I would not say one, but at least 4-5 packages, with a pretty good
>> confidence that more packages would be added later on.
>
> Gstreamer has added Meson as an alternative build system (to 
> Autotools) since August 2016:
>
> https://cgit.freedesktop.org/gstreamer/gstreamer/commit/meson.build?id=b2f9808722a0254acba17ef98a612a2792184e12

libepoxy is also another project that uses Meson build system. Since 1.4.0,
the "Building" section in README.md has commands to build with Meson:

  https://github.com/anholt/libepoxy/tree/1.4.1#building

Regards,
Fatih

[Buildroot] ninja/python-meson packages

[Vicente Olivert Riera]

libinput is another package that will migrate to meson, and it will stop
supporting autotools. From
https://lists.freedesktop.org/archives/wayland-devel/2017-June/034286.html :

"The first RC for libinput 1.8 is now available.

The biggest change in this release is that libinput has switched to
meson as primary build system, the 1.8.x releases are the last ones to
support (and be released with) autotools so you're encouraged to start
switching your build processes over to meson."

Regards,

Vincent

On 22/03/17 12:53, Fatih A??c? wrote:
> On Wednesday, November 9, 2016 6:26:38 PM +03, C?dric Marie wrote:
>> Hi,
>>
>> Regarding python-meson package that was proposed here:
>> http://lists.busybox.net/pipermail/buildroot/2016-June/163437.html
>>
>>>> However, I could provide a real package infrastructure named
>>>> "meson-package",
>>>> but as stated in the discussion about adding support for Cargo (the
>>>> Rust
>>>> package manager), to provide such infrastructure, at least one
>>>> package using
>>>> it should also be provided (it is sensible to have a working example of
>>>> the infrastructure).
>>
>>> I would not say one, but at least 4-5 packages, with a pretty good
>>> confidence that more packages would be added later on.
>>
>> Gstreamer has added Meson as an alternative build system (to
>> Autotools) since August 2016:
>>
>> https://cgit.freedesktop.org/gstreamer/gstreamer/commit/meson.build?id=b2f9808722a0254acba17ef98a612a2792184e12
>>
> 
> libepoxy is also another project that uses Meson build system. Since 1.4.0,
> the "Building" section in README.md has commands to build with Meson:
> 
>  https://github.com/anholt/libepoxy/tree/1.4.1#building
> 
> Regards,
> Fatih
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] ninja/python-meson packages

[Peter Korsgaard]

>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:

 > libinput is another package that will migrate to meson, and it will stop
 > supporting autotools. From
 > https://lists.freedesktop.org/archives/wayland-devel/2017-June/034286.html :

 > "The first RC for libinput 1.8 is now available.

 > The biggest change in this release is that libinput has switched to
 > meson as primary build system, the 1.8.x releases are the last ones to
 > support (and be released with) autotools so you're encouraged to start
 > switching your build processes over to meson."

Yes, I noticed that as well. We'll have to work on meson support
infrastructure relatively soon.

-- 
Bye, Peter Korsgaard