Re: [Mesa-dev] initial meson port

[Daniel Stone]

Hi,
Sorry for the top-post but the Gmail mobile app no longer believes in
inline quoting.

As for installing newer Meson, that's not strictly needed. As you say,
Meson deliberately doesn't have difficult or changing dependencies. It can
also be run straight from a checkout without mangling $PATH or $PYTHONPATH.
Just specify the full path to meson.py and everything will work from there.
I've been working with Meson like that for a year or so (old Debian
packages and a deep distrust of pip), and it's yet to break on me.

It would even be possible to automate this from an autogen-style script.
Having done the numbers for the Wayland conversion, doing this in-tree
still takes less space than generating all the piles of guff that autogen
creates in your tree.

Cheers,
Daniel

On Thu, 28 Sep 2017 at 6:25 pm, Dylan Baker  wrote:

> Quoting Tapani Pälli (2017-09-27 23:34:26)
> >
> >
> > On 09/27/2017 08:57 PM, Rob Herring wrote:
> > > On Wed, Sep 27, 2017 at 12:38 PM, Eric Anholt  wrote:
> > >> Dylan Baker  writes:
> > >>
> > >>> [ Unknown signature status ]
> > >>> I've gone ahead and pushed the Vulkan drivers meson builds.
> > >>>
> > >>> For those interested in helping finish the conversion, I have a
> branch
> > >>> "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965
> and most of
> > >>> the core classic mesa stack building. I'm working on GLX, then EGL
> to start
> > >>> testing this stack. Getting gallium building is my next step after
> that (it'll
> > >>> be RadeonSI because I have hardware).
> > >>>
> > >>> I'm also working on getting features into upstream meson to make
> meson more
> > >>> comfortable for mesa. Currently there are patches landed or pending
> for the two
> > >>> workarounds in the meson build we have currently (choosing the right
> linker and
> > >>> indexing into CustomTargets). I'm also still thinking about how we
> can share
> > >>> source files with the other 3 build systems already in mesa
> (autotools and
> > >>> android being the most important, since hopefully our meson will be
> able to
> > >>> support windows in the future, I don't know what will happen when
> android moves
> > >>> to blueprint/soong). If there is anything else please let me know.
> > >>
> > >> Talking with ChromeOS folks at XDC, it sounded like having Android.mk
> be
> > >> a small wrapper around another build system is a totally acceptable
> and
> > >> not unusual thing to do.  Rob, does that seem possible/OK to you?  It
> > >> seems like that should seriously reduce the android maintenance
> burden.
> > >
> > > I haven't come across any examples doing that, but it seems fine to me
> > > if that can work. I'd guess we just need to create a prebuilt target
> > > and somehow trigger it to run meson. It could be problematic if
> > > anything in mesa is a dependency on another project as there's some
> > > expectations about where things are built. But I don't think mesa is a
> > > dependency for anything.
> >
> > One possible issue is that meson and its dependencies are not part of
> > the supported toolchain for Android, would be surprised if this does not
> > become a problem on some level. As example version of Meson on Ubuntu
> > LTS (which is the tested and supported distro for android building) is
> > 0.29.0 while on Fedora 0.42.0.
>
> That will be a problem, I very much doubt that mesa will build with meson
> 0.29,
> and there are features going it 0.43 that I would like to depend on. Meson
> only
> has 2 hard requirements, python 3.4+ and ninja 1.6+, so it may be possible
> to
> install an updated meson via pip, but I suspect android will run into
> similar
> issues to windows, specifically that it needs a way to pass dependency
> locations.
>
> I've been looking at the possibility of generating blueprint from meson,
> which
> could the be checked into a branch, but there are some interface mismatches
> between meson and soong/blueprint and they could prove somewhat difficult
> to
> solve (specifically around arch specific files).
>
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Dylan Baker]

Quoting Tapani Pälli (2017-09-27 23:34:26)
> 
> 
> On 09/27/2017 08:57 PM, Rob Herring wrote:
> > On Wed, Sep 27, 2017 at 12:38 PM, Eric Anholt  wrote:
> >> Dylan Baker  writes:
> >>
> >>> [ Unknown signature status ]
> >>> I've gone ahead and pushed the Vulkan drivers meson builds.
> >>>
> >>> For those interested in helping finish the conversion, I have a branch
> >>> "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and 
> >>> most of
> >>> the core classic mesa stack building. I'm working on GLX, then EGL to 
> >>> start
> >>> testing this stack. Getting gallium building is my next step after that 
> >>> (it'll
> >>> be RadeonSI because I have hardware).
> >>>
> >>> I'm also working on getting features into upstream meson to make meson 
> >>> more
> >>> comfortable for mesa. Currently there are patches landed or pending for 
> >>> the two
> >>> workarounds in the meson build we have currently (choosing the right 
> >>> linker and
> >>> indexing into CustomTargets). I'm also still thinking about how we can 
> >>> share
> >>> source files with the other 3 build systems already in mesa (autotools and
> >>> android being the most important, since hopefully our meson will be able 
> >>> to
> >>> support windows in the future, I don't know what will happen when android 
> >>> moves
> >>> to blueprint/soong). If there is anything else please let me know.
> >>
> >> Talking with ChromeOS folks at XDC, it sounded like having Android.mk be
> >> a small wrapper around another build system is a totally acceptable and
> >> not unusual thing to do.  Rob, does that seem possible/OK to you?  It
> >> seems like that should seriously reduce the android maintenance burden.
> > 
> > I haven't come across any examples doing that, but it seems fine to me
> > if that can work. I'd guess we just need to create a prebuilt target
> > and somehow trigger it to run meson. It could be problematic if
> > anything in mesa is a dependency on another project as there's some
> > expectations about where things are built. But I don't think mesa is a
> > dependency for anything.
> 
> One possible issue is that meson and its dependencies are not part of 
> the supported toolchain for Android, would be surprised if this does not 
> become a problem on some level. As example version of Meson on Ubuntu 
> LTS (which is the tested and supported distro for android building) is 
> 0.29.0 while on Fedora 0.42.0.

That will be a problem, I very much doubt that mesa will build with meson 0.29,
and there are features going it 0.43 that I would like to depend on. Meson only
has 2 hard requirements, python 3.4+ and ninja 1.6+, so it may be possible to
install an updated meson via pip, but I suspect android will run into similar
issues to windows, specifically that it needs a way to pass dependency
locations.

I've been looking at the possibility of generating blueprint from meson, which
could the be checked into a branch, but there are some interface mismatches
between meson and soong/blueprint and they could prove somewhat difficult to
solve (specifically around arch specific files).

Dylan


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Tapani Pälli]

On 09/27/2017 08:57 PM, Rob Herring wrote:

On Wed, Sep 27, 2017 at 12:38 PM, Eric Anholt  wrote:

Dylan Baker  writes:


[ Unknown signature status ]
I've gone ahead and pushed the Vulkan drivers meson builds.

For those interested in helping finish the conversion, I have a branch
"wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most of
the core classic mesa stack building. I'm working on GLX, then EGL to start
testing this stack. Getting gallium building is my next step after that (it'll
be RadeonSI because I have hardware).

I'm also working on getting features into upstream meson to make meson more
comfortable for mesa. Currently there are patches landed or pending for the two
workarounds in the meson build we have currently (choosing the right linker and
indexing into CustomTargets). I'm also still thinking about how we can share
source files with the other 3 build systems already in mesa (autotools and
android being the most important, since hopefully our meson will be able to
support windows in the future, I don't know what will happen when android moves
to blueprint/soong). If there is anything else please let me know.


Talking with ChromeOS folks at XDC, it sounded like having Android.mk be
a small wrapper around another build system is a totally acceptable and
not unusual thing to do.  Rob, does that seem possible/OK to you?  It
seems like that should seriously reduce the android maintenance burden.


I haven't come across any examples doing that, but it seems fine to me
if that can work. I'd guess we just need to create a prebuilt target
and somehow trigger it to run meson. It could be problematic if
anything in mesa is a dependency on another project as there's some
expectations about where things are built. But I don't think mesa is a
dependency for anything.


One possible issue is that meson and its dependencies are not part of 
the supported toolchain for Android, would be surprised if this does not 
become a problem on some level. As example version of Meson on Ubuntu 
LTS (which is the tested and supported distro for android building) is 
0.29.0 while on Fedora 0.42.0.


// Tapani
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Rob Herring]

On Wed, Sep 27, 2017 at 12:38 PM, Eric Anholt  wrote:
> Dylan Baker  writes:
>
>> [ Unknown signature status ]
>> I've gone ahead and pushed the Vulkan drivers meson builds.
>>
>> For those interested in helping finish the conversion, I have a branch
>> "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most 
>> of
>> the core classic mesa stack building. I'm working on GLX, then EGL to start
>> testing this stack. Getting gallium building is my next step after that 
>> (it'll
>> be RadeonSI because I have hardware).
>>
>> I'm also working on getting features into upstream meson to make meson more
>> comfortable for mesa. Currently there are patches landed or pending for the 
>> two
>> workarounds in the meson build we have currently (choosing the right linker 
>> and
>> indexing into CustomTargets). I'm also still thinking about how we can share
>> source files with the other 3 build systems already in mesa (autotools and
>> android being the most important, since hopefully our meson will be able to
>> support windows in the future, I don't know what will happen when android 
>> moves
>> to blueprint/soong). If there is anything else please let me know.
>
> Talking with ChromeOS folks at XDC, it sounded like having Android.mk be
> a small wrapper around another build system is a totally acceptable and
> not unusual thing to do.  Rob, does that seem possible/OK to you?  It
> seems like that should seriously reduce the android maintenance burden.

I haven't come across any examples doing that, but it seems fine to me
if that can work. I'd guess we just need to create a prebuilt target
and somehow trigger it to run meson. It could be problematic if
anything in mesa is a dependency on another project as there's some
expectations about where things are built. But I don't think mesa is a
dependency for anything.

Rob
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Eric Anholt]

Dylan Baker  writes:

> [ Unknown signature status ]
> I've gone ahead and pushed the Vulkan drivers meson builds.
>
> For those interested in helping finish the conversion, I have a branch
> "wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most of
> the core classic mesa stack building. I'm working on GLX, then EGL to start
> testing this stack. Getting gallium building is my next step after that (it'll
> be RadeonSI because I have hardware).
>
> I'm also working on getting features into upstream meson to make meson more
> comfortable for mesa. Currently there are patches landed or pending for the 
> two
> workarounds in the meson build we have currently (choosing the right linker 
> and
> indexing into CustomTargets). I'm also still thinking about how we can share
> source files with the other 3 build systems already in mesa (autotools and
> android being the most important, since hopefully our meson will be able to
> support windows in the future, I don't know what will happen when android 
> moves
> to blueprint/soong). If there is anything else please let me know.

Talking with ChromeOS folks at XDC, it sounded like having Android.mk be
a small wrapper around another build system is a totally acceptable and
not unusual thing to do.  Rob, does that seem possible/OK to you?  It
seems like that should seriously reduce the android maintenance burden.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Dylan Baker]

I've gone ahead and pushed the Vulkan drivers meson builds.

For those interested in helping finish the conversion, I have a branch
"wip/meson-4" on my github (github.com/dcbaker/mesa) that has i965 and most of
the core classic mesa stack building. I'm working on GLX, then EGL to start
testing this stack. Getting gallium building is my next step after that (it'll
be RadeonSI because I have hardware).

I'm also working on getting features into upstream meson to make meson more
comfortable for mesa. Currently there are patches landed or pending for the two
workarounds in the meson build we have currently (choosing the right linker and
indexing into CustomTargets). I'm also still thinking about how we can share
source files with the other 3 build systems already in mesa (autotools and
android being the most important, since hopefully our meson will be able to
support windows in the future, I don't know what will happen when android moves
to blueprint/soong). If there is anything else please let me know.

Dylan

Quoting Dylan Baker (2017-09-20 13:27:37)
> Hi everyone,
> 
> A long time ago I made some rumbling about porting mesa to meson (isn't that
> confusing). In the mean time I've been bogged down with other projects,
> including adding features to meson itself, and trying to write and rebase 
> meson
> patches for all of mesa. Unfortunately mesa is a large fast moving project and
> trying to writing meson for the entire thing has proven to simply be
> intractable, I could spend nearly half my day rebasing to current master, and
> that's both demoralizing and error prone.
> 
> So I took Jason's advice and started with what mattered to him ;) Vulkan. This
> was a chunk big enough to be a decent example, but small and contained enough 
> to
> not require lots of rebasing. Intel's "anv" and the AMD "radv" driver share a
> large number of dependencies between each other, and demonstrate writing a 
> meson
> build system.
> 
> You may notice a lot of TODO/FIXME comments here. Some of them are related to
> upstream meson bugs (there are two currently, one that I have a pull request 
> for
> that is probably ready for merge, and one that I'm working on currently), or
> things that need to be implemented for the meson build system to be complete.
> There are a few things that will need to be resolved before implementing mesa
> and gallium drivers (around dependencies that are hard dependencies for 
> Vulkan,
> but soft dependencies for mesa/gallium).
> 
> The meson build system is much faster for building these two drivers than the
> autotools build system, but there are a couple of caveats worth mentioning
> before I give you the numbers. 1: meson doesn't check for as many features,
> flags, or dependencies; 2: meson doesn't build glx, egl, or the glsl compiler,
> just enough of the glsl_compiler to get anv and radv building. The 1st will 
> just
> naturally happen, the second could be fixed.
> 
> Methodology : I ran each build system in as close of a configuration as I 
> could
> (out of tree, same number of jobs) using zsh's time. These were run on a 2 
> core
> 4 thread Intel skylake. Note that ninja by default runs with logical cores + 2
> jobs.
> 
> Commands
> autotools : 'mkdir autotools ; cd autotools ; ../autogen.sh \
> --without-dri-drivers --without-gallium-drivers \
> --with-platforms=x11,wayland --with-vulkan-drivers=intel,radeon \
> && make -j6'
> meson : meson build -Dvulkan-drivers=intel,amd -Dplatforms=x11,wayland && 
> ninja -C build
> 
> Results
> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
> meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
> 
> I'm hopeful that we can start landing the meson build system incrementally, so
> that the rebasing pain can be eased. I'm working on getting i965 and radeonSI
> as my next targets (I have access to hardware to test those), and I'll 
> continue
> to add additional drivers from there.
> 
> Dylan
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Jose Fonseca]

On 21/09/17 01:20, Eric Anholt wrote:

Dylan Baker  writes:

Results
autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total


I just want to point at these numbers again.  meson is so transformative
for your normal build/test cycles that it's worth it even if we have to
duplicate source lists.  I know these aren't quite representative
because of all of automake's checks that haven't been done for meson,
but here's what we had for the X server conversion:

autotools:   meson:
no-op build  0.83 0.49
touch Makefile.am1.28
touch configure.ac  16.68
touch meson.build 2.92
clean ccache build  16.74 1.44
clean build 52.2427.84

Hopefully we can replace two of our build systems (hopefully android and
scons?) with this one, and then I think it will definitely be less
developer build system maintenance, even with duplicated source lists.
I'd be curious to hear what the vmware folks would need from meson in
order to drop scons, and I'd be willing to put in a good bit of work to
make it happen.


The idea of a unified build system for Mesa certainly appeals to me. 
And while I'm an happy CMake user, I don't think I'd ever pick scons 
again for a new projects, so personally I wouldn't be sorry to see it 
go.  That said, I simply can't comment on what I still don't know.


I'd like to complete the mesademos meson conversion first to gain better 
and 1st hand understanding of it.  I did try to collaborate on that, but 
I hit a wall, and I will need some help to make progress.


Namely we need to find a solution to consume stuff like glew/freeglut as 
DLL, without having to compile their sources with meson, because I'm 
afraid that porting glew/freeglut to meson in order to port mesademos on 
meson is simply a bit too big to chew, and the wrap modules are just too 
awkward to jump on for a beginner.  More on this on the separate thread.


Jose
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Eric Anholt]

Matt Turner  writes:

> On Thu, Sep 21, 2017 at 5:06 AM, Jakob Bornecrantz  
> wrote:
>> On Thu, Sep 21, 2017 at 2:20 AM, Eric Anholt  wrote:
>>> Dylan Baker  writes:
 Results
 autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
 meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
>>>
>>> I just want to point at these numbers again.  meson is so transformative
>>> for your normal build/test cycles that it's worth it even if we have to
>>> duplicate source lists.  I know these aren't quite representative
>>> because of all of automake's checks that haven't been done for meson,
>>> but here's what we had for the X server conversion:
>>>
>>> autotools:   meson:
>>> no-op build  0.83 0.49
>>> touch Makefile.am1.28
>>> touch configure.ac  16.68
>>> touch meson.build 2.92
>>> clean ccache build  16.74 1.44
>>> clean build 52.2427.84
>>>
>>> Hopefully we can replace two of our build systems (hopefully android and
>>> scons?) with this one, and then I think it will definitely be less
>>> developer build system maintenance, even with duplicated source lists.
>>> I'd be curious to hear what the vmware folks would need from meson in
>>> order to drop scons, and I'd be willing to put in a good bit of work to
>>> make it happen.
>>>
>>> Additionally, meson doesn't need the .hs listed in its source lists, so
>>> these meson.builds are actually more verbose than we need and would drop
>>> a huge source of our "fix up the build system" patches for automake's
>>> stupid distcheck.
>>
>> Wasn't lacking distcheck support one of the arguments against moving
>> to only a scons build when this was brought up all those years ago?
>> Does Meson provide something similar, or do people just now get all
>> of the source from git nowadays?
>
> Maybe that discussion was a before my time (or maybe I've just
> forgotten) but I did all of the work to make "make dist" work in
> ~2013. Building the tarballs and generating files like configure makes
> sense given the workings and limitations of autotools. I'd definitely
> be opposed to not making the tarballs with autotools' dist target
> because since we've switched we haven't shipped a broken tarball once,
> which was a common occurrence previously.
>
> With switching to Meson though, there's not the same need to generate
> all sorts of things and include them in the tarball. We'd add
> dependencies on python, mako, flex, and bison that we don't currently
> require to build from a tarball, but I think that's an acceptable
> cost.
>
> Just to preempt the question: as a (source-based) distribution
> maintainer, I'm against just getting the code from git. There's lots
> of distro infrastructure in place to mirror files and not any that I'm
> aware of to handle git repos.

Yeah.  You still want tarballs, you just want the tarballs to be
basically a snapshot of git so that everybody's using the same build
system.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Matt Turner]

On Thu, Sep 21, 2017 at 5:06 AM, Jakob Bornecrantz  wrote:
> On Thu, Sep 21, 2017 at 2:20 AM, Eric Anholt  wrote:
>> Dylan Baker  writes:
>>> Results
>>> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
>>> meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
>>
>> I just want to point at these numbers again.  meson is so transformative
>> for your normal build/test cycles that it's worth it even if we have to
>> duplicate source lists.  I know these aren't quite representative
>> because of all of automake's checks that haven't been done for meson,
>> but here's what we had for the X server conversion:
>>
>> autotools:   meson:
>> no-op build  0.83 0.49
>> touch Makefile.am1.28
>> touch configure.ac  16.68
>> touch meson.build 2.92
>> clean ccache build  16.74 1.44
>> clean build 52.2427.84
>>
>> Hopefully we can replace two of our build systems (hopefully android and
>> scons?) with this one, and then I think it will definitely be less
>> developer build system maintenance, even with duplicated source lists.
>> I'd be curious to hear what the vmware folks would need from meson in
>> order to drop scons, and I'd be willing to put in a good bit of work to
>> make it happen.
>>
>> Additionally, meson doesn't need the .hs listed in its source lists, so
>> these meson.builds are actually more verbose than we need and would drop
>> a huge source of our "fix up the build system" patches for automake's
>> stupid distcheck.
>
> Wasn't lacking distcheck support one of the arguments against moving
> to only a scons build when this was brought up all those years ago?
> Does Meson provide something similar, or do people just now get all
> of the source from git nowadays?

Maybe that discussion was a before my time (or maybe I've just
forgotten) but I did all of the work to make "make dist" work in
~2013. Building the tarballs and generating files like configure makes
sense given the workings and limitations of autotools. I'd definitely
be opposed to not making the tarballs with autotools' dist target
because since we've switched we haven't shipped a broken tarball once,
which was a common occurrence previously.

With switching to Meson though, there's not the same need to generate
all sorts of things and include them in the tarball. We'd add
dependencies on python, mako, flex, and bison that we don't currently
require to build from a tarball, but I think that's an acceptable
cost.

Just to preempt the question: as a (source-based) distribution
maintainer, I'm against just getting the code from git. There's lots
of distro infrastructure in place to mirror files and not any that I'm
aware of to handle git repos.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Nirbheek Chauhan]

On Thu, Sep 21, 2017 at 5:36 PM, Jakob Bornecrantz  wrote:
> Wasn't lacking distcheck support one of the arguments against moving
> to only a scons build when this was brought up all those years ago?
> Does Meson provide something similar, or do people just now get all
> of the source from git nowadays?
>

Meson supports a `dist` feature which is the same as `distcheck`.
However, it is less error-prone compared to Autotools distcheck
because it will tarball everything that has been checked into git
(once tests pass), so you don't have to maintain a whitelist of files.

This also means that you can be sure that your release contains the
same code that your git repository contains, and hence that your
release is buildable from both git and the tarball.

Cheers,
Nirbheek
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Jakob Bornecrantz]

On Thu, Sep 21, 2017 at 2:20 AM, Eric Anholt  wrote:
> Dylan Baker  writes:
>> Results
>> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
>> meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total
>
> I just want to point at these numbers again.  meson is so transformative
> for your normal build/test cycles that it's worth it even if we have to
> duplicate source lists.  I know these aren't quite representative
> because of all of automake's checks that haven't been done for meson,
> but here's what we had for the X server conversion:
>
> autotools:   meson:
> no-op build  0.83 0.49
> touch Makefile.am1.28
> touch configure.ac  16.68
> touch meson.build 2.92
> clean ccache build  16.74 1.44
> clean build 52.2427.84
>
> Hopefully we can replace two of our build systems (hopefully android and
> scons?) with this one, and then I think it will definitely be less
> developer build system maintenance, even with duplicated source lists.
> I'd be curious to hear what the vmware folks would need from meson in
> order to drop scons, and I'd be willing to put in a good bit of work to
> make it happen.
>
> Additionally, meson doesn't need the .hs listed in its source lists, so
> these meson.builds are actually more verbose than we need and would drop
> a huge source of our "fix up the build system" patches for automake's
> stupid distcheck.

Wasn't lacking distcheck support one of the arguments against moving
to only a scons build when this was brought up all those years ago?
Does Meson provide something similar, or do people just now get all
of the source from git nowadays?

Cheers, Jakob.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] initial meson port

[Eric Anholt]

Dylan Baker  writes:
> Results
> autotools : sh -c   535.34s user 30.33s system 310% cpu 3:02.05 total
> meson : sh -c   136.58s user 11.98s system 372% cpu 39.895 total

I just want to point at these numbers again.  meson is so transformative
for your normal build/test cycles that it's worth it even if we have to
duplicate source lists.  I know these aren't quite representative
because of all of automake's checks that haven't been done for meson,
but here's what we had for the X server conversion:

autotools:   meson:
no-op build  0.83 0.49
touch Makefile.am1.28
touch configure.ac  16.68
touch meson.build 2.92
clean ccache build  16.74 1.44
clean build 52.2427.84

Hopefully we can replace two of our build systems (hopefully android and
scons?) with this one, and then I think it will definitely be less
developer build system maintenance, even with duplicated source lists.
I'd be curious to hear what the vmware folks would need from meson in
order to drop scons, and I'd be willing to put in a good bit of work to
make it happen.

Additionally, meson doesn't need the .hs listed in its source lists, so
these meson.builds are actually more verbose than we need and would drop
a huge source of our "fix up the build system" patches for automake's
stupid distcheck.


signature.asc
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev