Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Timothy Arceri]

On 29/03/17 03:59, Emil Velikov wrote:

Hi Chad,

On 24 March 2017 at 20:44, Chad Versace  wrote:

On Tue 21 Mar 2017, Matt Turner wrote:

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  wrote:

On 20 March 2017 at 18:30, Matt Turner  wrote:

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  wrote:



These projects have been getting closer to upstream and "forcing" the
extra obstacle is effectively giving them the middle finger.


No. Requiring us to compile with a 10 year old GCC is giving a middle finger.


Can we stop with the GCC thing ? Can we point to a place where we want
to use feature A introduced with GCC B and we don't ?


Are you freaking serious?!

This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.


More examples:

- Jason and I wanted to use C11 generic expressions (that's what the
  C11 spec calls them) in anvil, but old GCC => !C11.


[snip]


freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
vulkan/anv_device.c:697:4: error: initializer element is not constant
freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen 
this? i'm on HEAD
freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 
strikes again?
freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely 
using gcc-4.9
freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that 
'(VkExtent3D)' looks very much pointless there
freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it happens, 
which is the "stable" gcc on gentoo
freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like 
chadv broke it


As mentioned elsewhere - if major stakeholders of $driver want to bump
the requirement, please do.
As an example: st/nine requires GCC 4.6 and st/clover GCC 4.7 for a
very long time.


That seems fine for optional state trackers but seems like a bad idea to 
encourage that for major drivers. It's likely to lead to features being 
used in common code.


I'm not actually against this, just pointing out the obvious.

Hopefully VMWARE will migrate to something newer at some stage. That 
seems to be the major blocker at this point in time.


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

Hi Chad,

On 24 March 2017 at 20:44, Chad Versace  wrote:
> On Tue 21 Mar 2017, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
>> wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> >> wrote:
>
>> >>> These projects have been getting closer to upstream and "forcing" the
>> >>> extra obstacle is effectively giving them the middle finger.
>> >>
>> >> No. Requiring us to compile with a 10 year old GCC is giving a middle 
>> >> finger.
>> >>
>> > Can we stop with the GCC thing ? Can we point to a place where we want
>> > to use feature A introduced with GCC B and we don't ?
>>
>> Are you freaking serious?!
>>
>> This happens *all* the time. It happened like two days ago with commit
>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>> happened at least once in the previous month, and every month before
>> that.
>
> More examples:
>
> - Jason and I wanted to use C11 generic expressions (that's what the
>   C11 spec calls them) in anvil, but old GCC => !C11.
>
[snip]
>
> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
> vulkan/anv_device.c:697:4: error: initializer element is not constant
> freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
> .minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
> freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen 
> this? i'm on HEAD
> freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 
> strikes again?
> freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm 
> definitely using gcc-4.9
> freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that 
> '(VkExtent3D)' looks very much pointless there
> freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it 
> happens, which is the "stable" gcc on gentoo
> freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like 
> chadv broke it

As mentioned elsewhere - if major stakeholders of $driver want to bump
the requirement, please do.
As an example: st/nine requires GCC 4.6 and st/clover GCC 4.7 for a
very long time.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Fri, Mar 24, 2017 at 11:47 AM, Jose Fonseca  wrote:
>
> Like I said in another email, maybe mesademos is a good way to get our feet
> wet.

jfwiw, I decided to figure out what this meson stuff is all about, and
converted kmscube (after adding an optional bit for video-cube, to
make it *slightly* more interesting).. it's (a) fast and (b) not hard
to figure out

https://lists.freedesktop.org/archives/mesa-dev/2017-March/149603.html

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-24 14:16:13)
> 
> Evaluating is one thing.  Actually migrating is another.
> 
> Brian already said he'd take a look and evaluate.  And I'll help in what 
> I can.  I agree we should all evaluate early.
> 
> 
> But I don't think that the proposal of first migrate scons to meson, 
> then in a second separate step migrate autotools to meson, is viable. 
> Like I said: there's no knowledge overlap.  The two group of people -- 
> the Meson and Windows experts -- will be chasing each other tails.  And 
> all that while, the build will continue to be broken or diverge because 
> master dev will go on.
> 
> 
> Jose

https://github.com/dcbaker/mesa-demos wip/meson

I've blindly ported some of the windows bits but have no way to test them, so
you can either delete the lot and go from scratch or see what's left to fix (the
wgl folder, for example). I have not implemented much of the windows or apple
logic in the root CMakeLists.txt, so hopefully that's useful for your purposes.

That branch also builds on my Archlinux machine, but not on debian due to
difference in the way they package freeglut I just ran out of time today. For
the record, I started at about 12:00, and finished at about 17:00 with a 1 hour
lunch in there. So about 3 hours to get a mostly working build. I'm going to try
to iron out the debian and travis issues either over the weekend or next week.

There is one difference, because ninja is non-recursive some targets would have
the same name and collide, so I've renamed some of the not installed binaries. I
believe that a non-recursive make (such as one generated by cmake) would have
the same problem. meson doesn't seem to have a method to rename the target, but
it's also a bit of an odd corner to build multiple binaries with the same name
that are both not installed and are for people (not automated build steps) to
use.

I also have a not quite working .travis.yml on that branch.

I'm also planning to get a mesa RFC sent out early next week once I get i965 and
llvmpipe building.

If we merge mesa we (Intel) will move to using meson as our primary build system
in CI (the one we run tests against) as soon as it's ready. Building mesa is
quite slow for us considering the power of our build hardware, and meson should
help with that. We'll continue to build autotools much the way we do scons now,
as a secondary "buildtest" only target.

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] [RFC libdrm 0/2] Replace the build system with meson

[Kenneth Graunke]

On Thursday, March 23, 2017 4:39:50 AM PDT Emil Velikov wrote:
> On 22 March 2017 at 20:10, Dylan Baker  wrote:
[snip]
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\

"Bug-free" - famous last words :)

It is definitely working a lot better than it used to.  I'm grateful
to those who helped make it so (yourself included).

> > For my part, it took me about 3 or 4 days of reading through the docs and
> > writing the libdrm port to get it right, and a lot of that is just the
> > boilerplate of having ~8 drivers that all need basically the same logic.
> >
> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?

As I believe Dylan explained...a lot of his time was spent learning
autotools and its idioms, so he knew how best to translate things.
(Dylan is pretty familiar with CMake, but less so with automake.)
Eric was able to work much more quickly, being already familiar with
the existing build system.

> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.
> 
> Thanks
> Emil

There's a time penalty figuring out any build system.  Most people try
to remain blissfully unaware of it as much as possible.  And then, most
tasks people do are pretty simple (adding files, deleting files, etc).
When something complex comes up...it takes time, reading, and sometimes
asking for help...no matter what system you use.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Juan A. Suarez Romero]

On Fri, 2017-03-24 at 10:13 -0700, Dylan Baker wrote:
> Quoting Jose Fonseca (2017-03-24 06:42:18)
> > 
> > I tend to disagree.  While we can't avoid a transitory period, when we 
> > embark on another build system (Meson or something else) I think we 
> > should aim at 1) ensure such tool can indeed _completely_ replace at 
> > least _one_ existing build system, 2) and aim at migration quickly.
> > 
> > Otherwise we'll just end up with yet another build system, yet another 
> > way builds can fail, with some developers stuck on old build systems 
> > because it works, or because the new build system quite doesn't work.
> > 
> > And this is from (painful) experience.
> 
> I tend to agree. Meson is *nice* because it's faster than autotools, but it's
> simplicity and the fact that it works for windows and *nix systems is one of 
> the
> best features. Having fewer build systems is better than more.
> 
> We had hoped that we could do one release with both autotools and meson, to 
> give
> some of the fast moving linux distributions (Arch, Fedora, etc) a chance to 
> help
> us iron out bugs, especially for pacakgers. I think it is important though to
> make a commitment for exactly when we're going to either migrate completely to
> meson, or abandon the attempt and revert it.
> 
> > So I think we should identify stake holders soon, collect requirements 
> > (OSes platforms, etc), make sure the prospective tool meets them, have 
> > all stakeholders collaborate on a prototype, them embark on mass migration.
> > 
> > That is, if this fails, let it fail early.  If it succeeds, may it 
> > succeed early.  Anything but a slow death / zombie life.
> 
> I have a branch that builds intel's Vulkan driver, I'm actively working to get
> intel's i965 dri driver and llvmpipe building and send that out as an RFC to
> mesa-dev. That should give us enough of mesa to evaluate the build system I
> hope (Since it touches all of the major mesa components [classic, gallium,
> neither]).
> 
> If other people are interested in collaborating I'd be happy to push the 
> branch
> sooner so that others can look at it.
> 
> I also think it's worth talking to Eric (who said he's porting X to meson),
> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer 
> (who
> has patches to port libinput to meson). If they're serious about seeing those
> land meson is even more appealing, since it would be a single build system 
> that
> all of the *nix graphics stack would be moving towards, and would mean that we
> wouldn't have an "Autotools for xorg", "meson for weston and libinput", 
> "cmake for
> piglit", and " for mesa".
> 

Some months ago I've also ported a module used in GNOME (grilo) to
Meson.

Faster-than-light when building is awesome. But the feature I can't
stress enough is how much simple and intuitive is working with Meson.
Everything looks quite more natural. And authors are very supportive.


> > BTW, how about migrating mesademos to Meson?  It currently has autotools 
> > and cmake.  I was hoping that cmake would replace autotools, but I 
> > couldn't run fast enough, so I couldn't practice what preached above, 
> > hence cmake doing almost but not all what autotools does.
> > 
> > And is not a crucial project for Linux distros -- few distros package it 
> > -- and even if they do, no other package would depend on it.  And is one 
> > of those sort of projects that should be easy to port to any build too.
> 
> That's definitely doable, but most distros do package it, it's where glxgears,
> and more importantly glxinfo live.
> 
> I'll have a look at it and see. At the very least we should be able to drop
> cmake since I very much doubt anyone but you guys use it.
> 
> > Even if we ignore everything else, just replacing autotools + cmake with 
> > just one thing would be a net win.
> > 
> > 
> > Jose
> 
> ___
> 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] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Fri, Mar 24, 2017 at 5:16 PM, Jose Fonseca  wrote:
> On 24/03/17 20:08, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca 
>> wrote:
>>>
>>> On 24/03/17 19:10, Kristian Høgsberg wrote:


 On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca 
 wrote:
>
>
> On 23/03/17 01:38, Rob Clark wrote:
>>
>>
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>>
>>>
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:



 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher
 
 wrote:
>
>
>
> I guess I'm a little late to the party here, but I haven't had time
> to
> really let all of this sink in and actually look at meson.  It
> doesn't
> seem so bad with a quick look and I think I could probably sort it
> out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar
> enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration
> based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we
> have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a
> big
> problem in my opinion.




 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't*
 know
 autotools well enough to get it right. Emil almost always finds
 cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the
 docs
 and
 writing the libdrm port to get it right, and a lot of that is just
 the
 boilerplate of having ~8 drivers that all need basically the same
 logic.

> Next, my bigger concern is for distro and casual packagers and
> people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require
> many
> of these existing tools and systems to be rewritten and then deal
> with
> the debugging and fall out from that.  The potential decreased
> build
> time is a nice bonus, but frankly a lot of people/companies have
> years
> of investment in existing tools.




 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are
 patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are
 working
 on. So
 even if we as a community decide that meson isn't for us, it's not
 going
 away.
>>>
>>>
>>>
>>>
>>> It is worth pointing out that it is currently required by no
>>> component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
>
>
> I tend to disagree.  While we can't avoid a transitory 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On Fri, Mar 24, 2017 at 2:16 PM, Jose Fonseca  wrote:

> On 24/03/17 20:08, Kristian Høgsberg wrote:
>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca 
>> wrote:
>>
>>> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>>

 On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca 
 wrote:

>
> On 23/03/17 01:38, Rob Clark wrote:
>
>>
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>
>>>
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>


 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <
 alexdeuc...@gmail.com>
 wrote:

>
>
> I guess I'm a little late to the party here, but I haven't had time
> to
> really let all of this sink in and actually look at meson.  It
> doesn't
> seem so bad with a quick look and I think I could probably sort it
> out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar
> enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration
> based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we
> have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a
> big
> problem in my opinion.
>



 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't*
 know
 autotools well enough to get it right. Emil almost always finds
 cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the
 docs
 and
 writing the libdrm port to get it right, and a lot of that is just
 the
 boilerplate of having ~8 drivers that all need basically the same
 logic.

 Next, my bigger concern is for distro and casual packagers and
> people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require
> many
> of these existing tools and systems to be rewritten and then deal
> with
> the debugging and fall out from that.  The potential decreased
> build
> time is a nice bonus, but frankly a lot of people/companies have
> years
> of investment in existing tools.
>



 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are
 patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are
 working
 on. So
 even if we as a community decide that meson isn't for us, it's not
 going
 away.

>>>
>>>
>>>
>>> It is worth pointing out that it is currently required by no
>>> component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>>
>
>
>
> I tend to disagree.  While we can't avoid a transitory 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 24/03/17 19:10, Kristian Høgsberg wrote:

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:

On 23/03/17 01:38, Rob Clark wrote:


On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:


On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:


On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
wrote:


I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson.  It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.



One of the things that's prompted this on our side (I've talked this
over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases
were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs
and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic.


Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.



Sure, but we're also not the only ones investigating meson. Gnome is
using it
already, libepoxy is using it, gstreamer is using it. There are patches
for
weston (written by Daniel Stone) and libinput (written by Peter
Hutterer), there
are some other projects in the graphics sphere that people are working
on. So
even if we as a community decide that meson isn't for us, it's not going
away.



It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new
maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.



but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

BR,
-R



I tend to disagree.  While we can't avoid a transitory period, when we
embark on another build system (Meson or something else) I think we should
aim at 1) ensure such tool can indeed _completely_ replace at least _one_
existing build system, 2) and aim at migration quickly.

Otherwise we'll just end up with yet another build system, yet another way
builds can fail, with some developers stuck on old build systems because it
works, or because the new build system quite doesn't work.

And this is from (painful) experience.


I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start using meson, which means that life gets easier for
vmware wrt maintaining the build system, and easier for all developers
who have spent to much of their life waiting for autogen.sh.  Then
decommissioning autotools can be a separate topic as Rob suggests,
something we'll do when the world is ready.


There's zero overlap between SCons 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 24/03/17 20:08, Kristian Høgsberg wrote:

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca  wrote:

On 24/03/17 19:10, Kristian Høgsberg wrote:


On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:


On 23/03/17 01:38, Rob Clark wrote:



On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:



On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:



On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
wrote:



I guess I'm a little late to the party here, but I haven't had time
to
really let all of this sink in and actually look at meson.  It
doesn't
seem so bad with a quick look and I think I could probably sort it
out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar
enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a
big
problem in my opinion.




One of the things that's prompted this on our side (I've talked this
over with
other people at Intel before starting), was that clearly we *don't*
know
autotools well enough to get it right. Emil almost always finds cases
were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs
and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same
logic.


Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal
with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have
years
of investment in existing tools.




Sure, but we're also not the only ones investigating meson. Gnome is
using it
already, libepoxy is using it, gstreamer is using it. There are
patches
for
weston (written by Daniel Stone) and libinput (written by Peter
Hutterer), there
are some other projects in the graphics sphere that people are working
on. So
even if we as a community decide that meson isn't for us, it's not
going
away.




It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new
maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.



but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

BR,
-R




I tend to disagree.  While we can't avoid a transitory period, when we
embark on another build system (Meson or something else) I think we
should
aim at 1) ensure such tool can indeed _completely_ replace at least _one_
existing build system, 2) and aim at migration quickly.

Otherwise we'll just end up with yet another build system, yet another
way
builds can fail, with some developers stuck on old build systems because
it
works, or because the new build system quite doesn't work.

And this is from (painful) experience.



I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start using meson, which means that life gets easier for
vmware wrt maintaining the build system, and easier for all developers
who have spent to much of their life waiting for autogen.sh.  Then
decommissioning 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Fri, Mar 24, 2017 at 3:10 PM, Kristian Høgsberg  wrote:
> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
>> On 23/03/17 01:38, Rob Clark wrote:
>>>
>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:

 On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
> wrote:
>>
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson.  It doesn't
>> seem so bad with a quick look and I think I could probably sort it out
>> when the time came, but there would still be a bit of a learning
>> curve.  While that may not be a big deal at the micro level, I have
>> concerns at the macro level.
>>
>> First, I'm concerned it may discourage casual developers and
>> packagers.  autotools isn't great, but most people are familiar enough
>> with it that they can get by.  Most people have enough knowledge of
>> autotools that they can pretty easily diagnose a configuration based
>> failure. There are a lot of resources for autotools.  I'm not sure
>> that would be the case for meson.  Do we as a community feel we have
>> enough meson experience to get people over the hump?  Anything that
>> makes it harder for someone to try a new build or do a bisect is a big
>> problem in my opinion.
>
>
> One of the things that's prompted this on our side (I've talked this
> over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases
> were we've
> done things *almost*, but not quite right.
>
> For my part, it took me about 3 or 4 days of reading through the docs
> and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic.
>
>> Next, my bigger concern is for distro and casual packagers and people
>> that maintain large build systems with lots of existing custom
>> configurations.  Changing from autotools would basically require many
>> of these existing tools and systems to be rewritten and then deal with
>> the debugging and fall out from that.  The potential decreased build
>> time is a nice bonus, but frankly a lot of people/companies have years
>> of investment in existing tools.
>
>
> Sure, but we're also not the only ones investigating meson. Gnome is
> using it
> already, libepoxy is using it, gstreamer is using it. There are patches
> for
> weston (written by Daniel Stone) and libinput (written by Peter
> Hutterer), there
> are some other projects in the graphics sphere that people are working
> on. So
> even if we as a community decide that meson isn't for us, it's not going
> away.


 It is worth pointing out that it is currently required by no component
 of an x.org stack.  In the case of libepoxy it was added by a new
 maintainer
 on a new release and even then autoconf remains.

 And as far as I can tell nothing in the entire OpenBSD ports tree
 currently requires meson to build including gnome and gstreamer.

>>>
>>> but I guess that is conflating two completely different topics..
>>> addition of meson and removal of autotools.  It is probably better
>>> that we treat the topics separately.  I don't see any way that the two
>>> can happen at the same time.
>>>
>>> The autotools build probably needs to remain for at least a couple
>>> releases, and I certainly wouldn't mind if some of the other desktop
>>> projects took the leap of dropping autotools first (at least then
>>> various different "distro" consumers will have already dealt with how
>>> to build meson packages)
>>>
>>> None of that blocks addition of a meson build system (or what various
>>> developers use day to day)
>>>
>>> BR,
>>> -R
>>
>>
>> I tend to disagree.  While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we should
>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>> existing build system, 2) and aim at migration quickly.
>>
>> Otherwise we'll just end up with yet another build system, yet another way
>> builds can fail, with some developers stuck on old build systems because it
>> works, or because the new build system quite doesn't work.
>>
>> And this is from (painful) experience.
>
> I agree, adding a meson build system should aim to phase out one of
> the other build systems within one or two release cycles. But (and
> maybe that was Robs point) that doesn't have be autotools. What if we
> phase out scons? It doesn't seem like anybody is really attached to it
> and if meson is as good as 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Chad Versace]

On Tue 21 Mar 2017, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov  
> wrote:
> > On 21 March 2017 at 15:57, Matt Turner  wrote:
> >> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
> >> wrote:
> >>> On 20 March 2017 at 18:30, Matt Turner  wrote:
>  On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>  wrote:


> Let me try one last time:
> 
> (1) Non-recursive automake is necessary for parallel build performance
> (2) Non-recursive automake is intractably unmaintainable for
> sufficiently large projects
> (3) Mesa is a sufficiently large project
> 
> Therefore using automake will be either bad for parallel build
> performance, unmaintainable, or both.
> 
> Meson aims to be a build system actually capable of replacing
> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
> cleaner domain specific language for writing the build rules, while
> generating non-recursive ninja build files. It does not use libtool.
> It supports Windows. It supports cross compilation.
> 
> And it has momentum: libepoxy already has a Meson build system. Others
> in the X.Org community are experimenting with it for libinput, Wayland
> and Weston, and the xserver.
> 
> All of that makes Meson very compelling.

Matt, I just wanted to say thanks for capturing in a nutshell the
argument for a Meson trial.

I want Meson because my builds are too slow. I regularly build an entire
fucking operating system from scratch (Chrome OS), and I cry when top
shows only 1 core at 100% and the other 47 cores sitting idle.

Autotools and libtool are often the culprit. The libtool penalty is paid
on every build, not just at configure time.

The only way to get all 48 cores closer to 100% is to (1) use
a non-recursive build system that (2) doesnt' use shell nor (3) libtool.

I don't care about new shiny. I'm often wary of new shiny things that
receive too much excitement.  Meson is a such a new shiny. But I'm
willing to overlook my aversion to new shiny Meson's immaturity if
it makes Chrome OS build faster... at least for Mesa.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Chad Versace]

On Tue 21 Mar 2017, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
> wrote:
> > On 20 March 2017 at 18:30, Matt Turner  wrote:
> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> >> wrote:

> >>> These projects have been getting closer to upstream and "forcing" the
> >>> extra obstacle is effectively giving them the middle finger.
> >>
> >> No. Requiring us to compile with a 10 year old GCC is giving a middle 
> >> finger.
> >>
> > Can we stop with the GCC thing ? Can we point to a place where we want
> > to use feature A introduced with GCC B and we don't ?
> 
> Are you freaking serious?!
> 
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.

More examples:

- Jason and I wanted to use C11 generic expressions (that's what the
  C11 spec calls them) in anvil, but old GCC => !C11.

- I *still* want to use _Generic.

- If we could use C11, then we could stop using the
  include/c11/thread.h wrapper for the C11 thread features. We could use,
  you know, *real* C11 threads instead of faking it.

- I want to do this:

  #define let __auto_type

  But __auto_type requires GCC 4.9
   or a comparably dated clang.

- I want to use GCC's builtin overflow arithmetic functions
   (such 
as
  __builtin_mul_overflow(), __builtin_add_overflow) where we currently do 
overflow checking by hand.
  The builtin functions are more secure (no chance of stupid mistakes) and
  faster (they simply do the arithmetic op then test the overflow flag in 
the
  CPU's status register).

- I tend to be guilty occasionally breaking the build in
  anvil code, due to old GCC. I think it happened again again this week:

freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
vulkan/anv_device.c:697:4: error: initializer element is not constant
freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen 
this? i'm on HEAD
freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 
strikes again?
freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely 
using gcc-4.9
freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that 
'(VkExtent3D)' looks very much pointless there
freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it 
happens, which is the "stable" gcc on gentoo
freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like 
chadv broke it
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca  wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:


 On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>
>
> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>
>>
>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
>> wrote:
>>>
>>>
>>> I guess I'm a little late to the party here, but I haven't had time
>>> to
>>> really let all of this sink in and actually look at meson.  It
>>> doesn't
>>> seem so bad with a quick look and I think I could probably sort it
>>> out
>>> when the time came, but there would still be a bit of a learning
>>> curve.  While that may not be a big deal at the micro level, I have
>>> concerns at the macro level.
>>>
>>> First, I'm concerned it may discourage casual developers and
>>> packagers.  autotools isn't great, but most people are familiar
>>> enough
>>> with it that they can get by.  Most people have enough knowledge of
>>> autotools that they can pretty easily diagnose a configuration based
>>> failure. There are a lot of resources for autotools.  I'm not sure
>>> that would be the case for meson.  Do we as a community feel we have
>>> enough meson experience to get people over the hump?  Anything that
>>> makes it harder for someone to try a new build or do a bisect is a
>>> big
>>> problem in my opinion.
>>
>>
>>
>> One of the things that's prompted this on our side (I've talked this
>> over with
>> other people at Intel before starting), was that clearly we *don't*
>> know
>> autotools well enough to get it right. Emil almost always finds cases
>> were we've
>> done things *almost*, but not quite right.
>>
>> For my part, it took me about 3 or 4 days of reading through the docs
>> and
>> writing the libdrm port to get it right, and a lot of that is just the
>> boilerplate of having ~8 drivers that all need basically the same
>> logic.
>>
>>> Next, my bigger concern is for distro and casual packagers and people
>>> that maintain large build systems with lots of existing custom
>>> configurations.  Changing from autotools would basically require many
>>> of these existing tools and systems to be rewritten and then deal
>>> with
>>> the debugging and fall out from that.  The potential decreased build
>>> time is a nice bonus, but frankly a lot of people/companies have
>>> years
>>> of investment in existing tools.
>>
>>
>>
>> Sure, but we're also not the only ones investigating meson. Gnome is
>> using it
>> already, libepoxy is using it, gstreamer is using it. There are
>> patches
>> for
>> weston (written by Daniel Stone) and libinput (written by Peter
>> Hutterer), there
>> are some other projects in the graphics sphere that people are working
>> on. So
>> even if we as a community decide that meson isn't for us, it's not
>> going
>> away.
>
>
>
> It is worth pointing out that it is currently required by no component
> of an x.org stack.  In the case of libepoxy it was added by a new
> maintainer
> on a new release and even then autoconf remains.
>
> And as far as I can tell nothing in the entire OpenBSD ports tree
> currently requires meson to build including gnome and gstreamer.
>

 but I guess that is conflating two completely different topics..
 addition of meson and removal of autotools.  It is probably better
 that we treat the topics separately.  I don't see any way that the two
 can happen at the same time.

 The autotools build probably needs to remain for at least a couple
 releases, and I certainly wouldn't mind if some of the other desktop
 projects took the leap of dropping autotools first (at least then
 various different "distro" consumers will have already dealt with how
 to build meson packages)

 None of that blocks addition of a meson build system (or what various
 developers use day to day)

 BR,
 -R
>>>
>>>
>>>
>>> I tend to disagree.  While we can't avoid a transitory period, when we
>>> embark on another build system (Meson or something else) I think we
>>> should
>>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>>> existing build system, 2) and aim at migration quickly.
>>>
>>> Otherwise we'll just end up with yet another build system, yet another
>>> way
>>> builds can fail, with some developers stuck on old build systems because
>>> it
>>> works, or because the new build system quite doesn't work.
>>>
>>> And this is from (painful) experience.
>>
>>
>> I agree, adding 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
> On 23/03/17 01:38, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:

 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
 wrote:
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.


 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't* know
 autotools well enough to get it right. Emil almost always finds cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the docs
 and
 writing the libdrm port to get it right, and a lot of that is just the
 boilerplate of having ~8 drivers that all need basically the same logic.

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.


 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are working
 on. So
 even if we as a community decide that meson isn't for us, it's not going
 away.
>>>
>>>
>>> It is worth pointing out that it is currently required by no component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
> I tend to disagree.  While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we should
> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
> existing build system, 2) and aim at migration quickly.
>
> Otherwise we'll just end up with yet another build system, yet another way
> builds can fail, with some developers stuck on old build systems because it
> works, or because the new build system quite doesn't work.
>
> And this is from (painful) experience.

I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Daniel Stone]

Hi,

On 24 March 2017 at 17:51, Eric Anholt  wrote:
> Dylan Baker  writes:
>> I also think it's worth talking to Eric (who said he's porting X to meson),
>> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer 
>> (who
>> has patches to port libinput to meson). If they're serious about seeing those
>> land meson is even more appealing, since it would be a single build system 
>> that
>> all of the *nix graphics stack would be moving towards, and would mean that 
>> we
>> wouldn't have an "Autotools for xorg", "meson for weston and libinput", 
>> "cmake for
>> piglit", and " for mesa".
>
> My desire is to push enough of X.org to Meson that I can actually do CI
> of the X Server.  Right now CI is not really tractable on Travis because
> autogen.sh of all the dependencies takes too long.

... and I'm equally serious about Wayland/Weston. I find how slow it
is infuriating for personal development, but for CI, it means that
there's no point trying to test different build options, since the
overhead is so high. Meson would let us actually do that.

I understand there's a huge amount of acquired folk knowledge we're
throwing away with autotools, and in the ~13 years since I started
working on moving X.Org to autotools, I've evaluated and discarded
most of the others because I didn't think they were sufficiently
compelling to do so. In terms of its featureset,
accessibility/tractability to mere mortals, etc, Meson is the only one
I've found where the advantages of moving outweighed the
disadvantages.

I've been pretty buried in atomic work lately, but am going to send
out a revised patchset for Wayland & Weston after I've got the next
iteration out. Similarly I'd expect to see one or two releases
shipping with both build systems, whilst we work with downstreams to
beat any bugs out of the new system before cutting over.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Dylan Baker  writes:

> [ Unknown signature status ]
> Quoting Jose Fonseca (2017-03-24 06:42:18)
>> 
>> I tend to disagree.  While we can't avoid a transitory period, when we 
>> embark on another build system (Meson or something else) I think we 
>> should aim at 1) ensure such tool can indeed _completely_ replace at 
>> least _one_ existing build system, 2) and aim at migration quickly.
>> 
>> Otherwise we'll just end up with yet another build system, yet another 
>> way builds can fail, with some developers stuck on old build systems 
>> because it works, or because the new build system quite doesn't work.
>> 
>> And this is from (painful) experience.
>
> I tend to agree. Meson is *nice* because it's faster than autotools, but it's
> simplicity and the fact that it works for windows and *nix systems is one of 
> the
> best features. Having fewer build systems is better than more.
>
> We had hoped that we could do one release with both autotools and meson, to 
> give
> some of the fast moving linux distributions (Arch, Fedora, etc) a chance to 
> help
> us iron out bugs, especially for pacakgers. I think it is important though to
> make a commitment for exactly when we're going to either migrate completely to
> meson, or abandon the attempt and revert it.
>
>> So I think we should identify stake holders soon, collect requirements 
>> (OSes platforms, etc), make sure the prospective tool meets them, have 
>> all stakeholders collaborate on a prototype, them embark on mass migration.
>> 
>> That is, if this fails, let it fail early.  If it succeeds, may it 
>> succeed early.  Anything but a slow death / zombie life.
>
> I have a branch that builds intel's Vulkan driver, I'm actively working to get
> intel's i965 dri driver and llvmpipe building and send that out as an RFC to
> mesa-dev. That should give us enough of mesa to evaluate the build system I
> hope (Since it touches all of the major mesa components [classic, gallium,
> neither]).
>
> If other people are interested in collaborating I'd be happy to push the 
> branch
> sooner so that others can look at it.
>
> I also think it's worth talking to Eric (who said he's porting X to meson),
> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer 
> (who
> has patches to port libinput to meson). If they're serious about seeing those
> land meson is even more appealing, since it would be a single build system 
> that
> all of the *nix graphics stack would be moving towards, and would mean that we
> wouldn't have an "Autotools for xorg", "meson for weston and libinput", 
> "cmake for
> piglit", and " for mesa".

My desire is to push enough of X.org to Meson that I can actually do CI
of the X Server.  Right now CI is not really tractable on Travis because
autogen.sh of all the dependencies takes too long.


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] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-24 06:42:18)
> 
> I tend to disagree.  While we can't avoid a transitory period, when we 
> embark on another build system (Meson or something else) I think we 
> should aim at 1) ensure such tool can indeed _completely_ replace at 
> least _one_ existing build system, 2) and aim at migration quickly.
> 
> Otherwise we'll just end up with yet another build system, yet another 
> way builds can fail, with some developers stuck on old build systems 
> because it works, or because the new build system quite doesn't work.
> 
> And this is from (painful) experience.

I tend to agree. Meson is *nice* because it's faster than autotools, but it's
simplicity and the fact that it works for windows and *nix systems is one of the
best features. Having fewer build systems is better than more.

We had hoped that we could do one release with both autotools and meson, to give
some of the fast moving linux distributions (Arch, Fedora, etc) a chance to help
us iron out bugs, especially for pacakgers. I think it is important though to
make a commitment for exactly when we're going to either migrate completely to
meson, or abandon the attempt and revert it.

> So I think we should identify stake holders soon, collect requirements 
> (OSes platforms, etc), make sure the prospective tool meets them, have 
> all stakeholders collaborate on a prototype, them embark on mass migration.
> 
> That is, if this fails, let it fail early.  If it succeeds, may it 
> succeed early.  Anything but a slow death / zombie life.

I have a branch that builds intel's Vulkan driver, I'm actively working to get
intel's i965 dri driver and llvmpipe building and send that out as an RFC to
mesa-dev. That should give us enough of mesa to evaluate the build system I
hope (Since it touches all of the major mesa components [classic, gallium,
neither]).

If other people are interested in collaborating I'd be happy to push the branch
sooner so that others can look at it.

I also think it's worth talking to Eric (who said he's porting X to meson),
Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who
has patches to port libinput to meson). If they're serious about seeing those
land meson is even more appealing, since it would be a single build system that
all of the *nix graphics stack would be moving towards, and would mean that we
wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake 
for
piglit", and " for mesa".

> BTW, how about migrating mesademos to Meson?  It currently has autotools 
> and cmake.  I was hoping that cmake would replace autotools, but I 
> couldn't run fast enough, so I couldn't practice what preached above, 
> hence cmake doing almost but not all what autotools does.
> 
> And is not a crucial project for Linux distros -- few distros package it 
> -- and even if they do, no other package would depend on it.  And is one 
> of those sort of projects that should be easy to port to any build too.

That's definitely doable, but most distros do package it, it's where glxgears,
and more importantly glxinfo live.

I'll have a look at it and see. At the very least we should be able to drop
cmake since I very much doubt anyone but you guys use it.

> Even if we ignore everything else, just replacing autotools + cmake with 
> just one thing would be a net win.
> 
> 
> Jose


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[randyf]

On Mon, 20 Mar 2017, Matt Turner wrote:




 - dropping the Autotools will lead to OpenBSD and NetBSD having to
write one from scratch, IIRC Solaris/FreeBSD and others are in similar
boat.


Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.



  For the parts that are relevant to this discussion, this isn't true. 
Yes, the core OS is closed (Oracle Solaris, not the OpenSolaris 
derivative), but the entire graphics stack, including kernel graphics 
drivers are available on java.net and/or github.



  That developers haven't been contributing is primarily due to a 
significant amount of work required on a small set of developers in an 
attempt to just catch up, but they are listening.  What a migration to 
new build system would mean is another item in the list requiring more 
catch-up.



  That said (and I hope I don't get into too hot water), I don't think it 
would be an extremely difficult task for Solaris to migrate; just would 
require resources.



  Cheers!

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 17:03:58)
> On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker  wrote:
> >
> > I'm hoping you can clarify a couple of questions I have about blueprint:
> > 1) android is moving to blueprint from android.mk files?
> 
> Yes, in a phased transition.  We support both for now.
> 
> > 2) is there a publicly available project that uses blueprint I could look 
> > at?
> >The documentation I've been able to find is pretty sparse.
> 
> Blueprint is a framework for writing build systems, and Soong is
> AOSP's Blueprint build system.  See
> https://android.googlesource.com/platform/build/soong/+/master/README.md
> for documentation on Soong.

Thanks, that's very useful information.


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Bas Nieuwenhuizen]

> Another tool I heard good about but have not direct experience is
> https://bazel.build .  Any thoughts about it?

Having looked a bit into it, it also is just a build system (albeit
higher level than ninja or make). It doesn't do configure or install
and working with system dependencies is annoying. While it is awesome
at some stuff, I think for these reasons mesa just is not a good
usecase for it.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 24/03/17 14:22, Daniel Stone wrote:

Hi Jose,

On 24 March 2017 at 14:03, Jose Fonseca  wrote:

On 22/03/17 20:57, Dylan Baker wrote:

Cross compiling for mingw is supported, and it provides a way to
differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag
for
this, but the meson approach is to write an ini file once, and use it
again and
again), and the first example of cross compiling is using mingw from linux
[2].


[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation



Thanks for the info.

It still scares me a bit that most Meson users are mostly Linux focused.


That's not actually true ...

A lot of the reason GStreamer went towards Meson is because it has
native OS X (XCode project) and Windows (MinGW or Visual Studio
project) support. Meson's own source tree goes out of its way to use
spaces in directory and file names for its test suite, to make sure
that that support never breaks. Every build of Meson is CI'd on
AppVeyor as well as Travis for OS X. And of course, the GStreamer CI
uses Meson for its non-Linux builds.

It's true that a lot of the projects taking an interest of late have
been Linux, yes. But if you're native to Windows / OS X, you just use
VS/Xcode. There are (IMO) very few properly cross-platform projects
who are 'Windows projects with a port' or 'mainly OS X but also runs
on Linux', rather than cross-platform 'Linux projects'.


OK.


Another tool I heard good about but have not direct experience is
https://bazel.build .  Any thoughts about it?


If you look at the FAQ, one of the first things you'll see is that
they don't properly support Windows. It also requires Java to run,
which I'd say would be a no-go if people are already complaining about
the impossibility of installing several megabytes of Python stdlib.


I see.  Indeed.


Thanks.  From the label on the tin, it does sound like Meson ticks a lot 
of boxes then.



Like I said in another email, maybe mesademos is a good way to get our 
feet wet.


I can't guarantee I'll be able to dedicate much time, but at least get 
AppVeyor builds of it, since it has been a long objective of mine to get 
mesademos/piglit/etc builds on AppVeyor instead of a private Jenkins server.



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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Daniel Stone]

Hi Jose,

On 24 March 2017 at 14:03, Jose Fonseca  wrote:
> On 22/03/17 20:57, Dylan Baker wrote:
>> Cross compiling for mingw is supported, and it provides a way to
>> differentiate
>> the build, host, and target machines [1], I've cross compiled for
>> aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag
>> for
>> this, but the meson approach is to write an ini file once, and use it
>> again and
>> again), and the first example of cross compiling is using mingw from linux
>> [2].
>>
>>
>> [1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
>> [2]https://github.com/mesonbuild/meson/wiki/Cross-compilation
>
>
> Thanks for the info.
>
> It still scares me a bit that most Meson users are mostly Linux focused.

That's not actually true ...

A lot of the reason GStreamer went towards Meson is because it has
native OS X (XCode project) and Windows (MinGW or Visual Studio
project) support. Meson's own source tree goes out of its way to use
spaces in directory and file names for its test suite, to make sure
that that support never breaks. Every build of Meson is CI'd on
AppVeyor as well as Travis for OS X. And of course, the GStreamer CI
uses Meson for its non-Linux builds.

It's true that a lot of the projects taking an interest of late have
been Linux, yes. But if you're native to Windows / OS X, you just use
VS/Xcode. There are (IMO) very few properly cross-platform projects
who are 'Windows projects with a port' or 'mainly OS X but also runs
on Linux', rather than cross-platform 'Linux projects'.

> Another tool I heard good about but have not direct experience is
> https://bazel.build .  Any thoughts about it?

If you look at the FAQ, one of the first things you'll see is that
they don't properly support Windows. It also requires Java to run,
which I'd say would be a no-go if people are already complaining about
the impossibility of installing several megabytes of Python stdlib.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 22/03/17 20:57, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-22 10:59:10)

On 17/03/17 02:28, Brian Paul wrote:


[snip]

Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build
system.  Replacing SCons with Meson could be a big deal in that
context.  It would at least involve pulling Meson into our toolchain and
rewriting a bunch of Python code to grok Meson.  I'd have to go off and
investigate that to even see if it's a possibility.  Maybe next week.



I don't have any experience with Meson.  But for the record I don't have
much love for SCons.  I long stopped using SCons for anything but Mesa.

And my have good experience with cmake + ninja/msvc is positive.  So
tools with similar architecture sound good overall.

In fact, knowing what I know now, if I could go back in time, to when I
evaluated CMake and SCons, I'd chose CMake.


BTW, it seems that newer SCons will drop Python 2 support [1], which
might force us to rewrite a lot of SConsfiles/scripts any way.  So
perhaps that's a good time to evaluate migrating to something else.



That said, moving to another build system is always a herculian task.
Thought the benefit of having a single build system is appealing and
might save time down the line.



But there are many questions I have about Meson:  how confident are we
on Meson?  Are big projects using it?  How sure are we that it won't
become abandonware in a few years time?  How does it compare with other
newer gen build systems?



Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users

Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.

As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.

For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.

I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.



We also have special requirements: one is cross-build from Linux to
MinGW, which on Mesa case requires building portions of the tree twice
-- once for host -- another for cross-mingw.


Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2].

[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation


Thanks for the info.

It still scares me a bit that most Meson users are mostly Linux focused.

Another tool I heard good about but have not direct experience is 
https://bazel.build .  Any thoughts about it?




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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 23/03/17 01:38, Rob Clark wrote:

On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:

I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson.  It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.


One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic.


Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.


Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.


It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.



but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

BR,
-R


I tend to disagree.  While we can't avoid a transitory period, when we 
embark on another build system (Meson or something else) I think we 
should aim at 1) ensure such tool can indeed _completely_ replace at 
least _one_ existing build system, 2) and aim at migration quickly.


Otherwise we'll just end up with yet another build system, yet another 
way builds can fail, with some developers stuck on old build systems 
because it works, or because the new build system quite doesn't work.


And this is from (painful) experience.



So I think we should identify stake holders soon, collect requirements 
(OSes platforms, etc), make sure the prospective tool meets them, have 
all stakeholders collaborate on a prototype, them embark on mass migration.


That is, if this fails, let it fail early.  If it succeeds, may it 
succeed early.  Anything but a slow death / zombie life.





BTW, how about migrating mesademos to Meson?  It currently has autotools 
and cmake.  I was hoping that cmake would replace autotools, but I 
couldn't run fast enough, so I couldn't practice what preached above, 
hence cmake doing almost but not all what autotools does.


And is not a crucial project for Linux distros -- few distros package it 
-- and even if they do, no other package would depend on it.  And is one 
of those sort of projects that should be easy to port to any build too.


Even if we ignore everything else, just replacing autotools + cmake with 
just one thing would be a net win.

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Colin Cross]

On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker  wrote:
> Quoting Colin Cross (2017-03-23 15:14:16)
>> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
>> > On 03/22/2017 02:48 PM, Rob Clark wrote:
>> >>
>> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
>> >>>
>> >>> Quoting Rob Clark (2017-03-22 10:07:54)
>> 
>>  I guess an interesting question (from someone who doesn't know meson
>>  yet) would be whether meson could slurp in the Makefile.sources type
>>  stuff that we have, which are shared so far between
>>  android/scons/autotools (and for the most part, kept developers from
>>  having to care *too* much about the different build systems)
>> >>>
>> >>>
>> >>> Jason and I have talked about that too. I'd suggested that we could write
>> >>> a
>> >>> module for meson to read makefile.sources (since we're surely not the
>> >>> only
>> >>> project that would benefit from such a module), except that android is
>> >>> moving to
>> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>> >>> doesn't
>> >>> support using makefile.sources, so it seems somewhat moot in a world of
>> >>> blueprint for android, meson for *.
>> >>
>> >>
>> >> I guess even if it is only a temporary thing, something that could
>> >> slurp in Makefile.sources seems like it would be useful for a
>> >> transition period.
>> >>
>> >> I'm not totally up to speed on android/blueprint stuff.. but even some
>> >> simplified or different "here-are-my-sources" type file that could be
>> >> shared across build systems would be useful.  Meson sounds a bit more
>> >> extensible so maybe there is some potential to adapt to whatever
>> >> android forces on us ;-)
>> >
>> >
>> > +ccross from the Android build team can hopefully provide some input here.
>>
>> For cases like this, we generally add a python script that translates
>> the build files into something Blueprint understands, and rerun it
>> each time we import into the project.
>>
>> Alternatively, Blueprint efficiently supports globbing for sources, so
>> if all the source files are always listed in Makefile.sources (which
>> seems to be true in our copy of libdrm except for intel/test_decode.c)
>> then we could use globs and ignore the makefiles, possibly manually
>> excluding a few files.
>
> I'm hoping you can clarify a couple of questions I have about blueprint:
> 1) android is moving to blueprint from android.mk files?

Yes, in a phased transition.  We support both for now.

> 2) is there a publicly available project that uses blueprint I could look at?
>The documentation I've been able to find is pretty sparse.

Blueprint is a framework for writing build systems, and Soong is
AOSP's Blueprint build system.  See
https://android.googlesource.com/platform/build/soong/+/master/README.md
for documentation on Soong.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Colin Cross]

On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
> On 03/22/2017 02:48 PM, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
>>>
>>> Quoting Rob Clark (2017-03-22 10:07:54)

 I guess an interesting question (from someone who doesn't know meson
 yet) would be whether meson could slurp in the Makefile.sources type
 stuff that we have, which are shared so far between
 android/scons/autotools (and for the most part, kept developers from
 having to care *too* much about the different build systems)
>>>
>>>
>>> Jason and I have talked about that too. I'd suggested that we could write
>>> a
>>> module for meson to read makefile.sources (since we're surely not the
>>> only
>>> project that would benefit from such a module), except that android is
>>> moving to
>>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
>>> doesn't
>>> support using makefile.sources, so it seems somewhat moot in a world of
>>> blueprint for android, meson for *.
>>
>>
>> I guess even if it is only a temporary thing, something that could
>> slurp in Makefile.sources seems like it would be useful for a
>> transition period.
>>
>> I'm not totally up to speed on android/blueprint stuff.. but even some
>> simplified or different "here-are-my-sources" type file that could be
>> shared across build systems would be useful.  Meson sounds a bit more
>> extensible so maybe there is some potential to adapt to whatever
>> android forces on us ;-)
>
>
> +ccross from the Android build team can hopefully provide some input here.

For cases like this, we generally add a python script that translates
the build files into something Blueprint understands, and rerun it
each time we import into the project.

Alternatively, Blueprint efficiently supports globbing for sources, so
if all the source files are always listed in Makefile.sources (which
seems to be true in our copy of libdrm except for intel/test_decode.c)
then we could use globs and ignore the makefiles, possibly manually
excluding a few files.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 15:14:16)
> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann  wrote:
> > On 03/22/2017 02:48 PM, Rob Clark wrote:
> >>
> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
> >>>
> >>> Quoting Rob Clark (2017-03-22 10:07:54)
> 
>  I guess an interesting question (from someone who doesn't know meson
>  yet) would be whether meson could slurp in the Makefile.sources type
>  stuff that we have, which are shared so far between
>  android/scons/autotools (and for the most part, kept developers from
>  having to care *too* much about the different build systems)
> >>>
> >>>
> >>> Jason and I have talked about that too. I'd suggested that we could write
> >>> a
> >>> module for meson to read makefile.sources (since we're surely not the
> >>> only
> >>> project that would benefit from such a module), except that android is
> >>> moving to
> >>> blueprint[1] instead of android.mk files. As far as I can tell blueprint
> >>> doesn't
> >>> support using makefile.sources, so it seems somewhat moot in a world of
> >>> blueprint for android, meson for *.
> >>
> >>
> >> I guess even if it is only a temporary thing, something that could
> >> slurp in Makefile.sources seems like it would be useful for a
> >> transition period.
> >>
> >> I'm not totally up to speed on android/blueprint stuff.. but even some
> >> simplified or different "here-are-my-sources" type file that could be
> >> shared across build systems would be useful.  Meson sounds a bit more
> >> extensible so maybe there is some potential to adapt to whatever
> >> android forces on us ;-)
> >
> >
> > +ccross from the Android build team can hopefully provide some input here.
> 
> For cases like this, we generally add a python script that translates
> the build files into something Blueprint understands, and rerun it
> each time we import into the project.
> 
> Alternatively, Blueprint efficiently supports globbing for sources, so
> if all the source files are always listed in Makefile.sources (which
> seems to be true in our copy of libdrm except for intel/test_decode.c)
> then we could use globs and ignore the makefiles, possibly manually
> excluding a few files.

I'm hoping you can clarify a couple of questions I have about blueprint:
1) android is moving to blueprint from android.mk files?
2) is there a publicly available project that uses blueprint I could look at?
   The documentation I've been able to find is pretty sparse.

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] [RFC libdrm 0/2] Replace the build system with meson

[Greg Hackmann]

On 03/22/2017 02:48 PM, Rob Clark wrote:

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:

Quoting Rob Clark (2017-03-22 10:07:54)

I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, which are shared so far between
android/scons/autotools (and for the most part, kept developers from
having to care *too* much about the different build systems)


Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.


I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.

I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful.  Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)


+ccross from the Android build team can hopefully provide some input here.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 05:00, Jonathan Gray  wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> > > wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
>
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
>
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
>
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie
>
> commit d3d340d6026e516cc405a2eb1d925a7a7a467480
> Author: Jonathan Gray 
> Date:   Thu Mar 16 00:30:07 2017 +1100
>
> i965: don't use designated array initialisation
>
> Don't use a form of designated array initialisation that breaks gcc 4.2.1.
>
Jonathan, I think you meant to say:
Using C99 designated initializers is not allowed in C++ code, thus the
compiler may warn or even fail.

>
> Signed-off-by: Jonathan Gray 
>
> diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
> b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> index 4a8b5be30e..e7a502306e 100644
> --- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
> +++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
> @@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
> emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
>  }
>
> -static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
We already have C helper get_hw_prim_for_gl_prim that we can use instead.
I'll send a patch in a minute.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Emil Velikov (2017-03-23 04:39:50)
> On 22 March 2017 at 20:10, Dylan Baker  wrote:
> 
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\

Sure, but if it's easier to get right (which I'm asserting it is), then meson
should pay off in the long run by needing less maintenance to remain "bug-free",
since fewer bugs will be introduced.

> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?

Mostly talking with Matt about which patterns from autotools don't make sense to
port to meson. Also in those 3-4 days were a stab at mesa that made me realize
it was too big a of project for the first go, and picking a smaller, simpler
first project made sense. Honestly the about half of that time was spent reading
autotools documentation to figure out what some of the macros did, and then
reading meson bugs to figure out what the meson equivalent is. I have
familiarity with cmake, but this was the first major work with autotools I've
done. At this point working on Mesa the meson is just coming and I spend a lot
more time reading autotools documentation and asking Matt "What does X do, and
does it have side effects?"

> 
> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.

Eric (who as done a lot more autotools than me) said it took him 2 days to
become a more comfortable with meson than autotools, having written autotools
for 10 years. Asking Eric, Daniel Stone, or Peter Hutterer, who all have much
more autotools experience than me, would probably be more useful to answer that
question. I can say this, it took me significantly less time to become fluent
with meson than to become passable with cmake.

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] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> > 
> > 
> > On 21/03/17 06:39, Emil Velikov wrote:
> > > On 20 March 2017 at 18:30, Matt Turner  wrote:
> > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov 
> > > >  wrote:
> > > > > Seems like we ended up all over the place, so let me try afresh.
> > > > > 
> > > > > Above all:
> > > > >  - Saying "I don't care" about your users is arrogant - let us _not_
> > > > > do that, please ?
> > > > 
> > > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > > GCC,
> > > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > > wasn't OpenBSD to blame here ;-)
> > 
> > Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> > switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> > 
> > Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> > rather not go through the upgrade hassle if I don't have to."
> > 
> > Followed by Jose "We're internally building and shipping Mesa compiled with
> > GCC 4.4 (more specifically 4.4.3).
> > 
> > It's fine if you require GCC 4.8 on automake, but please leave support
> > for GCC 4.4.x in SCons."
> > 
> > By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> > various features backported, from what I understand Mesa would not build on
> > a real GCC 4.2 release and we should not be using it as a min version. IMO
> > if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> > the min GCC version.
> > 
> > I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> > deal with it if we move on.
> 
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.
> 
> We have one platform using clang/lld now (arm64) and are likely to move
> others in future where possible.  libtool has to be patched and the Mesa
> configure script regenerated to make this work or Mesa won't build due
> to libtool.m4 looking for specific strings in ld -v produced by bfd
> binutils or gold...
> 
> And yes if you change the configure script to check for a newer version
> I'll revert it locally like I did with the zlib one.
> 
> As I get the impression no one cares about patches for older GCC I've
> not being sending them to the list, ie

And to be clear this is code in Mesa violating the C++ standard
according to clang++ --std=c++14 -pedantic.

compiler/brw_vec4_gs_visitor.cpp:589:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_POINTS] =_3DPRIM_POINTLIST,
   ^~
compiler/brw_vec4_gs_visitor.cpp:590:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINES] = _3DPRIM_LINELIST,
   ^
compiler/brw_vec4_gs_visitor.cpp:591:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
   ^
compiler/brw_vec4_gs_visitor.cpp:592:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:593:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLES] = _3DPRIM_TRILIST,
   ^~~~
compiler/brw_vec4_gs_visitor.cpp:594:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
   ^~
compiler/brw_vec4_gs_visitor.cpp:595:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
   ^~
compiler/brw_vec4_gs_visitor.cpp:596:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_QUADS] = _3DPRIM_QUADLIST,
   ^
compiler/brw_vec4_gs_visitor.cpp:597:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:598:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_POLYGON] = _3DPRIM_POLYGON,
   ^~
compiler/brw_vec4_gs_visitor.cpp:599:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   [GL_LINES_ADJACENCY] = _3DPRIM_LINELIST_ADJ,
   ^~~
compiler/brw_vec4_gs_visitor.cpp:600:4: warning: designated initializers are a 
C99 feature [-Wc99-extensions]
   

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 22 March 2017 at 20:10, Dylan Baker  wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson.  It doesn't
>> seem so bad with a quick look and I think I could probably sort it out
>> when the time came, but there would still be a bit of a learning
>> curve.  While that may not be a big deal at the micro level, I have
>> concerns at the macro level.
>>
>> First, I'm concerned it may discourage casual developers and
>> packagers.  autotools isn't great, but most people are familiar enough
>> with it that they can get by.  Most people have enough knowledge of
>> autotools that they can pretty easily diagnose a configuration based
>> failure. There are a lot of resources for autotools.  I'm not sure
>> that would be the case for meson.  Do we as a community feel we have
>> enough meson experience to get people over the hump?  Anything that
>> makes it harder for someone to try a new build or do a bisect is a big
>> problem in my opinion.
>
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right.
You do know that I'm always happy to answer questions and help people
;-) Just last night I gave a 2 minute crash course to Lyude why things
behave strange and how to get the desired workflow.

> Emil almost always finds cases were we've
> done things *almost*, but not quite right.
>
Care I say it - I'm a pessimist forged by unfortunate circumstances.
Hence I always see things that are wrong - Mesa build system is no
exception.
I'm fairly confident that if/when we move to Meson we (I?) will be
fixing bugs for at least two releases.

The more frustrating part is that atm autotools build is "bug-free"
and with meson will have to go through the same route again :-\

> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic.
>
Slightly off-topic - 3 days to write the build script for ~10 [nearly]
identical libraries which do not do anything fancy, seems a lot.
Which was the most time consuming part ?

I'm concerned that we would have to enforce the same time penalty onto
dozens of developers unfamiliar with meson.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jani Nikula]

On Wed, 22 Mar 2017, Dylan Baker  wrote:
> Quoting Jani Nikula (2017-03-22 01:24:19)
>> Right. That helps avoid many of the issues e.g. Sphinx has with the
>> configuration files being pure python.
>
> Yes, sphinx's configuration files are awful for just that reason.

Of course, for the exact same reason they are so flexible you can work
around all the problems. ;)

J.


-- 
Jani Nikula, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
>> > I guess I'm a little late to the party here, but I haven't had time to
>> > really let all of this sink in and actually look at meson.  It doesn't
>> > seem so bad with a quick look and I think I could probably sort it out
>> > when the time came, but there would still be a bit of a learning
>> > curve.  While that may not be a big deal at the micro level, I have
>> > concerns at the macro level.
>> >
>> > First, I'm concerned it may discourage casual developers and
>> > packagers.  autotools isn't great, but most people are familiar enough
>> > with it that they can get by.  Most people have enough knowledge of
>> > autotools that they can pretty easily diagnose a configuration based
>> > failure. There are a lot of resources for autotools.  I'm not sure
>> > that would be the case for meson.  Do we as a community feel we have
>> > enough meson experience to get people over the hump?  Anything that
>> > makes it harder for someone to try a new build or do a bisect is a big
>> > problem in my opinion.
>>
>> One of the things that's prompted this on our side (I've talked this over 
>> with
>> other people at Intel before starting), was that clearly we *don't* know
>> autotools well enough to get it right. Emil almost always finds cases were 
>> we've
>> done things *almost*, but not quite right.
>>
>> For my part, it took me about 3 or 4 days of reading through the docs and
>> writing the libdrm port to get it right, and a lot of that is just the
>> boilerplate of having ~8 drivers that all need basically the same logic.
>>
>> > Next, my bigger concern is for distro and casual packagers and people
>> > that maintain large build systems with lots of existing custom
>> > configurations.  Changing from autotools would basically require many
>> > of these existing tools and systems to be rewritten and then deal with
>> > the debugging and fall out from that.  The potential decreased build
>> > time is a nice bonus, but frankly a lot of people/companies have years
>> > of investment in existing tools.
>>
>> Sure, but we're also not the only ones investigating meson. Gnome is using it
>> already, libepoxy is using it, gstreamer is using it. There are patches for
>> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
>> there
>> are some other projects in the graphics sphere that people are working on. So
>> even if we as a community decide that meson isn't for us, it's not going 
>> away.
>
> It is worth pointing out that it is currently required by no component
> of an x.org stack.  In the case of libepoxy it was added by a new maintainer
> on a new release and even then autoconf remains.
>
> And as far as I can tell nothing in the entire OpenBSD ports tree
> currently requires meson to build including gnome and gstreamer.
>

but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> > I guess I'm a little late to the party here, but I haven't had time to
> > really let all of this sink in and actually look at meson.  It doesn't
> > seem so bad with a quick look and I think I could probably sort it out
> > when the time came, but there would still be a bit of a learning
> > curve.  While that may not be a big deal at the micro level, I have
> > concerns at the macro level.
> >
> > First, I'm concerned it may discourage casual developers and
> > packagers.  autotools isn't great, but most people are familiar enough
> > with it that they can get by.  Most people have enough knowledge of
> > autotools that they can pretty easily diagnose a configuration based
> > failure. There are a lot of resources for autotools.  I'm not sure
> > that would be the case for meson.  Do we as a community feel we have
> > enough meson experience to get people over the hump?  Anything that
> > makes it harder for someone to try a new build or do a bisect is a big
> > problem in my opinion.
> 
> One of the things that's prompted this on our side (I've talked this over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases were 
> we've
> done things *almost*, but not quite right.
> 
> For my part, it took me about 3 or 4 days of reading through the docs and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic. 
> 
> > Next, my bigger concern is for distro and casual packagers and people
> > that maintain large build systems with lots of existing custom
> > configurations.  Changing from autotools would basically require many
> > of these existing tools and systems to be rewritten and then deal with
> > the debugging and fall out from that.  The potential decreased build
> > time is a nice bonus, but frankly a lot of people/companies have years
> > of investment in existing tools.
> 
> Sure, but we're also not the only ones investigating meson. Gnome is using it
> already, libepoxy is using it, gstreamer is using it. There are patches for
> weston (written by Daniel Stone) and libinput (written by Peter Hutterer), 
> there
> are some other projects in the graphics sphere that people are working on. So
> even if we as a community decide that meson isn't for us, it's not going away.

It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.

> 
> Quoting Rob Clark (2017-03-22 10:07:54)
> > I guess an interesting question (from someone who doesn't know meson
> > yet) would be whether meson could slurp in the Makefile.sources type
> > stuff that we have, which are shared so far between
> > android/scons/autotools (and for the most part, kept developers from
> > having to care *too* much about the different build systems)
> 
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.
> 
> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
> 
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.
> 
> [1] https://godoc.org/github.com/google/blueprint
> > 
> > If so, that makes it easier to coexist with existing build systems.  I
> > don't think it would be a good idea to remove the autotools build
> > anytime soon.. that should be the last one removed, after meson has
> > replaced scons (and hopefully android?)
> 
> I would imagine that if we did merge meson, we would make at the very least 
> one
> release with meson and autotools (scons is VMWare's thing, they can migrate at
> their leisure), if not two, to 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Eric Anholt (2017-03-22 15:15:46)
> Rob Clark  writes:
> 
> > On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
> >> Here's a not so complete list: 
> >> https://github.com/mesonbuild/meson/wiki/Users
> >>
> >> Notably gnome is moving to meson (and some parts already use it), weston 
> >> and
> >> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> >> can't say for sure it's going to be around forever, but its been in 
> >> development
> >> since late 2012 and still lands several patches a day, they were 
> >> responsive to
> >> me when I sent a patch (that I still need to respin), and they seem to be
> >> picking up momentum from downstreams.
> >
> >
> > btw, possibly newbie question, but from what I can tell so far in
> > meson docs, there are separate 'meson build && cd build && ninja'
> > steps.. one nice thing about autotools is 'git pull && make' (and it
> > somehow magically figures out whether to re-automake/autoconf).  Not
> > sure if there is a way to do something like that in meson.
> 
> Consider meson build to be ./autogen.sh.  After that point you can git
> pull && make.

Additionally, ninja has the same -C flag as make. So that can be 'meson build &&
ninja -C build' and 'git pull && ninja -C build'


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Alex Deucher  writes:

> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
>> Why bother, and why would we want this?  
>> │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D= more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
>> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

Meson is so much nicer for the casual contributor than autoconf.  I've
been hacking at converting the X Server for two days, and I'm now far
more capable at meson than have ever been at autotools, and I've been
doing autotools for 15 years (I don't know how many autotools build
systems I've written over that time, but it's in the tens at least).

I think meson is a win for new users already.  I think we get into even
bigger wins when we consider the use of wrap when there's no distro copy
of a library -- just imagine never having to write instructions like the
"X Server" or "Mesa" parts of this page again:
https://github.com/anholt/mesa/wiki/VC4-complete-Raspbian-upgrade


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Rob Clark  writes:

> On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
>> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>>
>> Notably gnome is moving to meson (and some parts already use it), weston and
>> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
>> can't say for sure it's going to be around forever, but its been in 
>> development
>> since late 2012 and still lands several patches a day, they were responsive 
>> to
>> me when I sent a patch (that I still need to respin), and they seem to be
>> picking up momentum from downstreams.
>
>
> btw, possibly newbie question, but from what I can tell so far in
> meson docs, there are separate 'meson build && cd build && ninja'
> steps.. one nice thing about autotools is 'git pull && make' (and it
> somehow magically figures out whether to re-automake/autoconf).  Not
> sure if there is a way to do something like that in meson.

Consider meson build to be ./autogen.sh.  After that point you can git
pull && make.


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] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 4:57 PM, Dylan Baker  wrote:
> Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users
>
> Notably gnome is moving to meson (and some parts already use it), weston and
> libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
> can't say for sure it's going to be around forever, but its been in 
> development
> since late 2012 and still lands several patches a day, they were responsive to
> me when I sent a patch (that I still need to respin), and they seem to be
> picking up momentum from downstreams.


btw, possibly newbie question, but from what I can tell so far in
meson docs, there are separate 'meson build && cd build && ninja'
steps.. one nice thing about autotools is 'git pull && make' (and it
somehow magically figures out whether to re-automake/autoconf).  Not
sure if there is a way to do something like that in meson.

(I nearly always use separate build and debug builddirs w/ autotools,
so that part I don't mind.. you can git-pull from a subdir fo the git
tree)

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker  wrote:
> Quoting Rob Clark (2017-03-22 10:07:54)
>> I guess an interesting question (from someone who doesn't know meson
>> yet) would be whether meson could slurp in the Makefile.sources type
>> stuff that we have, which are shared so far between
>> android/scons/autotools (and for the most part, kept developers from
>> having to care *too* much about the different build systems)
>
> Jason and I have talked about that too. I'd suggested that we could write a
> module for meson to read makefile.sources (since we're surely not the only
> project that would benefit from such a module), except that android is moving 
> to
> blueprint[1] instead of android.mk files. As far as I can tell blueprint 
> doesn't
> support using makefile.sources, so it seems somewhat moot in a world of
> blueprint for android, meson for *.

I guess even if it is only a temporary thing, something that could
slurp in Makefile.sources seems like it would be useful for a
transition period.

I'm not totally up to speed on android/blueprint stuff.. but even some
simplified or different "here-are-my-sources" type file that could be
shared across build systems would be useful.  Meson sounds a bit more
extensible so maybe there is some potential to adapt to whatever
android forces on us ;-)


> I don't think that meson should try to generate blueprint files, since 
> blueprint
> is itself a metabuild system that generates ninja files, and is self
> boot-strapping Go code. I don't know if the community is going to want 
> blueprint
> to live in repo either, since one actually writes Go code for the build 
> system.
> (I'm not objecting prematurely, I'm just pointing out that the design is
> significantly different the Android.mk, and the community will probably want 
> to
> re-evaluate)
>
> If android doesn't mandate a migration to blueprint, or blueprint does handle
> makefile.sources (I don't think it does), I'd be happy to propose a module for
> meson that could read makefile.sources, and write said module, and get said
> module upstream.

I guess from my PoV with my developer hat on, as long as simple things
like adding/removing src files to an existing .so or .a require just
editing one build file for all build systems, that pretty much
guarantees that I don't forget to update one and anger
windows/android/$other_random_thing builders ;-)

(with my $enterprise_distro hat on, I think *probably* the main thing
is that we don't drop autotools build support before
gnome/gstreamer/etc.. not 100% sure about the py3 dependency but I
guess if we aren't the only one that needs it to build, that helps..)

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-22 01:24:19)
> On Tue, 21 Mar 2017, Dylan Baker  wrote:
> > Quoting Jani Nikula (2017-03-21 07:44:55)
> >> How does meson handle build file backwards compatibility between meson
> >> versions? I don't intend to flame, but I've found for some reason many
> >> python projects don't seem to take this very seriously. Either having
> >> conditionals in build files to support building with several meson
> >> versions or always requiring the latest and greatest version would be
> >> rather annoying.
> >
> > Meson makes backwards compatible changes, and the version can be
> > queried using `meson.version()`, which works using meson's version
> > comparison mechanism. I would say this about meson, it's not a 'python
> > project', it's 'a project written in python',
> 
> This is what I meant above, although I clearly didn't write it that way.

I don't think I was exactly clear in what I said either, I would describe SCons
as a "python project", and meson as a "project written in python", since SCons
is python and has some of the warts that make backwards compatibility in python
projects hard (changes that work in the majority case break in some niche use
cases), where meson has a parser/generator written in python.

> > and they've taken great pains to not expose python in meson, and
> > reserve the right to reimplement in a different language if python
> > becomes an issue.
> 
> Right. That helps avoid many of the issues e.g. Sphinx has with the
> configuration files being pure python.

Yes, sphinx's configuration files are awful for just that reason.

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] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-22 10:59:10)
> On 17/03/17 02:28, Brian Paul wrote:
> >
> > [snip]
> >
> > Sure, I'd like to see one build system instead of two.  Meson supports
> > Windows so that's good.  But the big issue is our automated build
> > system.  Replacing SCons with Meson could be a big deal in that
> > context.  It would at least involve pulling Meson into our toolchain and
> > rewriting a bunch of Python code to grok Meson.  I'd have to go off and
> > investigate that to even see if it's a possibility.  Maybe next week.
> 
> 
> I don't have any experience with Meson.  But for the record I don't have 
> much love for SCons.  I long stopped using SCons for anything but Mesa.
> 
> And my have good experience with cmake + ninja/msvc is positive.  So 
> tools with similar architecture sound good overall.
> 
> In fact, knowing what I know now, if I could go back in time, to when I 
> evaluated CMake and SCons, I'd chose CMake.
> 
> 
> BTW, it seems that newer SCons will drop Python 2 support [1], which 
> might force us to rewrite a lot of SConsfiles/scripts any way.  So 
> perhaps that's a good time to evaluate migrating to something else.
> 
> 
> 
> That said, moving to another build system is always a herculian task. 
> Thought the benefit of having a single build system is appealing and 
> might save time down the line.
>
>
>
> But there are many questions I have about Meson:  how confident are we 
> on Meson?  Are big projects using it?  How sure are we that it won't 
> become abandonware in a few years time?  How does it compare with other 
> newer gen build systems?
> 

Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users

Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.

As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.

For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.

I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.

> 
> We also have special requirements: one is cross-build from Linux to 
> MinGW, which on Mesa case requires building portions of the tree twice 
> -- once for host -- another for cross-mingw.

Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2]. 

[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation

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] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.

One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic. 

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.

Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.

Quoting Rob Clark (2017-03-22 10:07:54)
> I guess an interesting question (from someone who doesn't know meson
> yet) would be whether meson could slurp in the Makefile.sources type
> stuff that we have, which are shared so far between
> android/scons/autotools (and for the most part, kept developers from
> having to care *too* much about the different build systems)

Jason and I have talked about that too. I'd suggested that we could write a
module for meson to read makefile.sources (since we're surely not the only
project that would benefit from such a module), except that android is moving to
blueprint[1] instead of android.mk files. As far as I can tell blueprint doesn't
support using makefile.sources, so it seems somewhat moot in a world of
blueprint for android, meson for *.

I don't think that meson should try to generate blueprint files, since blueprint
is itself a metabuild system that generates ninja files, and is self
boot-strapping Go code. I don't know if the community is going to want blueprint
to live in repo either, since one actually writes Go code for the build system.
(I'm not objecting prematurely, I'm just pointing out that the design is
significantly different the Android.mk, and the community will probably want to
re-evaluate)

If android doesn't mandate a migration to blueprint, or blueprint does handle
makefile.sources (I don't think it does), I'd be happy to propose a module for
meson that could read makefile.sources, and write said module, and get said
module upstream.

[1] https://godoc.org/github.com/google/blueprint
> 
> If so, that makes it easier to coexist with existing build systems.  I
> don't think it would be a good idea to remove the autotools build
> anytime soon.. that should be the last one removed, after meson has
> replaced scons (and hopefully android?)

I would imagine that if we did merge meson, we would make at the very least one
release with meson and autotools (scons is VMWare's thing, they can migrate at
their leisure), if not two, to give us a chance to flush out the bugs and to
give various distros who don't have meson ready yet a chance. It'll also give
the fast moving and aggressive distros like Arch and Fedora and chance to
migrate and report bugs.

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] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 17/03/17 02:28, Brian Paul wrote:

On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand > wrote:

On March 16, 2017 5:41:24 PM Emil Velikov > wrote:

On 17 March 2017 at 00:21, Dylan Baker > wrote:

Hi Emil,

Quoting Emil Velikov (2017-03-16 16:35:33)

While I can see you're impressed by Meson, I would
kindly urge you to
not use it here. As you look closely you can see that
one could
trivially improve the times, yet the biggest thing is
that most of the
code in libdrm must go ;-)


Perhaps I wasn't clear enough, I don't really expect this to
land ever. I sent
it out more because I'd written it and it works and is a
useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds
isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be
4 minutes to 1
minute, and that is a huge difference in time.

You are still failing to see past your usecase. As said before - if
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any
situation.


Yes, you can't just linearly apply any scaling factor.  However,
when you build mesa on a machine with a decent number of threads (I
think our build machine for the CI system has 32 threads),
autotools+make is slow as mud.  Also, there's very little you can do
to speed up configure since it's a pile of shell and perl that
inherently runs single-threaded and is fairly complex due to mesa's
complicated dependencies.

As the port is not 1:1 wrt the autoconf one, the
performance numbers
above are comparing apples to oranges.


I fail to see what I'm missing from meson that would have an
effect on the
times I reported. There are some files that are installed by
autoconf that I
didn't bother to install with meson (because I don't expect
this to land). Since
I didn't time installs, I don't see how it isn't an apples
to apples comparison.

You already (explicitly) mentioned some differences. Admittedly
not a
deal breaker.

I understand that libdrm is a pessimal case for
recursive-make since most
sub folders contain < 5 C files, However, even if you were
to flatten the make
files meson+ninja would still be faster when you consider
that meson
configures and builds faster than autotools configures.

That's correct. If is so concerned - they should slim down the
configure.ac  ;-)


There are real limits as to what you can do there.

If you/others are unhappy with the build times of libdrm
- poke me on
IRC. I will give you some easy tips on how to improve those.

You have some good python knowledge - I would kindly
urge you to
improve/rewrite the slow and/or hacky python scripts we
have in mesa.
This is a topic that was mentioned multiple times, and a
part where
everyone will be glad to see some progress.

Thanks
Emil


The real goal here is to do mesa (in case I didn't make that
clear either), and
the advantage for mesa is not just performance, it's that
meson supports visual
studio on windows; which means that we could hopefully not
just get faster
builds, but also replace both autotools and scons with a
single build system.

Yes that was more than clear. Yet it won't fly, I'm afraid.

The VMWare people like their SCons,


??



How much?  I would really rather the VMWare people speak on behalf
of VMWare.  Meson is the single best shot we've ever had for
replacing both with one build system.  I'm sure the VMware people
would like to have a build system that gets maintained by the
community as a whole.


Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build
system.  Replacing SCons with Meson could be a big deal in that
context.  It would at least involve pulling Meson into our toolchain and
rewriting a bunch of Python code to grok Meson.  I'd have to go off and
investigate that to even see if it's a possibility.  Maybe next week.



I 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Marek Olšák]

On Wed, Mar 22, 2017 at 6:26 PM, Jose Fonseca  wrote:
> On 16/03/17 22:36, Marek Olšák wrote:
>>
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors in stderr?
>>
>> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> wouldn't like any project that I might be involved in to require ninja
>> for building.

I also use Qt Creator.

Here is the ninja branch that keeps errors in stderr:
https://github.com/dendy/ninja/tree/segmented-output

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 16/03/17 22:36, Marek Olšák wrote:

Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?

I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't like any project that I might be involved in to require ninja
for building.

Marek


Yes, that's an annoying behavior from ninja.

I use a simple shell script for IDEs that care about that (e.g., with 
QtCreator):


  $ cat `which ninja-stderr `
  #!/bin/sh
  ninja "$@" 1>&2

There's a rationale for ninja to behave like that -- ninja buffers the 
whole program output, but and they use a combined buffer for both stderr 
and stdout so lines appear in same order.  Still, it would be nice if 
they fixed this for everybody.


Jose

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 19:10, Matt Turner  wrote:
> On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov  
> wrote:
>> On 21 March 2017 at 18:06, Matt Turner  wrote:
>>> (1) Non-recursive automake is necessary for parallel build performance
>> Fully agree
>>
>>> (2) Non-recursive automake is intractably unmaintainable for
>>> sufficiently large projects
>> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable 
>> ?
>
> Not by itself.
>
> src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.
>
Perfect - I can sort out the ~60 gallium Makefiles which constitutes
in ~half of mesa quite quickly.
As those are sorted I'll look at the more picky ones and ensuring that
the contains remain as trivial as possible.

Will you/anyone be interested in skimming through the patches ?

>> Does it have "dist", "check", "distcheck" or less commonly used
>
> Our thinking is that by switching to a build system that doesn't
> require large amounts of generated code (configure, Makefile.in, etc),
> we will stop shipping the code generated by the build system in the
> tarballs (which would just be created by git archive). None of that is
> set in stone.
>
Where can I read-up on the discussion ?

Would be great if we don't bring back the flex/bison/other requirement
for people building from tarballs. Still ... there may be some good
arguments against that.

>> "ctags" "cscope"  targets ?
>
> I don't know.
>
>>> And it has momentum: libepoxy already has a Meson build system. Others
>>> in the X.Org community are experimenting with it for libinput, Wayland
>>> and Weston, and the xserver.
>>>
>>> All of that makes Meson very compelling.
>> That's the thing - I'm never said that it's _not_ a very compelling project.
>> I'm saying that it's not there yet - mostly due to the list above.
>
> Perfect. Since no one claimed it's "there yet" there is nothing to
> disagree about.

Ack. In the interim we can make our existing build more performant, right ?

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
>> Why bother, and why would we want this?  
>> │~
>>
>> First it's written in python, which means the potential developer base
>> is massive. And it provides a recursive view for humans, but a
>> non-recursive view for the system. This is the best of both worlds,
>> humans can organize the build system in a way that makes sense, and the
>> machine gets a non-recursive build system. It also uses ninja rather
>> than make, and ninja is faster than make inherently. Meson is also a
>> simpler syntax than autotools or cmake it's not Turing Complete by
>> design nor does it expose python, again, by design. This allows meson
>> itself to be reimplemented in a another language if python becomes a
>> dead-end or a bottle-neck. It also makes it much easier to understand
>> what the build system is doing.
>>
>> What's different about using meson?
>>
>> Well, apart from a faster builds and less magic in the build system? The
>> configure flags are different, it uses -D= more like cmake
>> than the --enable or --with flags of autotools, although oddly it uses
>> --prefix and friends when calling meson, but not with mesonconf, there's
>> a bug opened on this. Meson also doesn't support in-tree builds at all;
>> all builds are done out of tree. It also doesn't provide a "make dist"
>> target, fortunately there's this awesome tool called git, and it
>> provides a "git archive" command that does much the same thing. Did I
>> mention it's fast?
>>
>> Here are the performance numbers I see on a 2 core 4 thread SKL, without
>> initial configuration, and building out of tree (using zsh):
>>
>> For meson the command line is:
>> time (meson build -Dmanpages=true && ninja -C build)
>>
>> For autotools the command line is:
>> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>>
>> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
>> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
>> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
>> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>>
>> That's ~4x faster for a cold build and ~10x faster for a hot build.
>>
>> For a make clean && make style build with a hot cache:
>> meson: 4.64s user 0.33s system 334% cpu 1.486 total
>> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>>
>> Why bother with libdrm?
>>
>> It's a simple build system, that could be completely (or mostly
>> completely) be ported in a very short time, and could serve as a tech
>> demo for the advantages of using meson to garner feedback for embarking
>> on a larger project, like mesa (which is what I'm planning to work on
>> next).
>>
>> tl;dr
>>
>> I wrote this as practice for porting Mesa, and figured I might as well
>> send it out since I wrote it.
>>
>> It is very likely that neither of these large patches will show up on the
>> mailing list, but this is available at my github:
>> https://github.com/dcbaker/libdrm wip/meson
>
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.
>
> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.
>

I guess an interesting question (from someone who doesn't know meson
yet) would be whether meson could slurp in the Makefile.sources type
stuff that we have, which are shared so far between
android/scons/autotools (and for the most part, kept developers from
having to care *too* much about the different build systems)

If so, that makes it easier to 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Alex Deucher]

On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
> Why bother, and why would we want this?   
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson


I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson.  It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.

Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.

my 2 cents.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jani Nikula]

On Tue, 21 Mar 2017, Dylan Baker  wrote:
> Quoting Jani Nikula (2017-03-21 07:44:55)
>> How does meson handle build file backwards compatibility between meson
>> versions? I don't intend to flame, but I've found for some reason many
>> python projects don't seem to take this very seriously. Either having
>> conditionals in build files to support building with several meson
>> versions or always requiring the latest and greatest version would be
>> rather annoying.
>
> Meson makes backwards compatible changes, and the version can be
> queried using `meson.version()`, which works using meson's version
> comparison mechanism. I would say this about meson, it's not a 'python
> project', it's 'a project written in python',

This is what I meant above, although I clearly didn't write it that way.

> and they've taken great pains to not expose python in meson, and
> reserve the right to reimplement in a different language if python
> becomes an issue.

Right. That helps avoid many of the issues e.g. Sphinx has with the
configuration files being pure python.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 09:22:50AM -0700, Dylan Baker wrote:
> Quoting Jani Nikula (2017-03-21 07:44:55)
> > On Thu, 16 Mar 2017, Dylan Baker  wrote:
> > > First it's written in python, [...]
> > 
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> 
> Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
> released in 2012. It's also worth nothing that a couple of us have been 
> working
> to get mesa's python scripts python3 compatible, so in the (hopefully) near
> future python2 wouldn't be required.

Mesa only requires python for development versions not to build
releases.  Changing to a build system that uses python3 to parse JSON
like files to generate ninja would change that.

> 
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> 
> Meson makes backwards compatible changes, and the version can be queried using
> `meson.version()`, which works using meson's version comparison mechanism. I
> would say this about meson, it's not a 'python project', it's 'a project 
> written
> in python', and they've taken great pains to not expose python in meson, and
> reserve the right to reimplement in a different language if python becomes an
> issue.
> 
> 
> > BR,
> > Jani.
> > 
> > -- 
> > Jani Nikula, Intel Open Source Technology Center
> 
> 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] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hey Kai,

Quoting Kai Wasserbäch (2017-03-21 11:36:31)
> I hope the rest of the Mesa project would follow such a rule. Because if 
> there's
> something I absolutely hate about all those "new" build systems, then it's 
> their
> tendency to just download stuff and build/include that. This seems to have 
> risen
> with Node and now spread into Rust and other parts of the FLOSS eco-system.

I think we have enough distro people in the project that they would revert a use
of wrap on linux :)

> CMake or SCons would do the same AFAICS. Plus CMake seems to be used in the
> Android eco-system already
> (), which might mean it
> could be easier for the Android downstreams of Mesa? Not sure on that though.

I don't think this really helps our android problem, since mesa is part of the
core anrdoid tree for devices using mesa, it needs android.mk files (I think
someone mentioned that they're migrating to blueprint?), and that doesn't
support cmake, autotools, scons, or meson. If meson is useful I'm willing to
propose and write an android.mk or blueprint backend for meson if the meson
community wants it.

> > 2) meson much simpler than autotools, scons, or (especially) cmake
> 
> OTOH CMake gives you CTest/CDash
> (), CPack
> (), dependency
> visualisation
> () and
> many other things for (basically) free. Maybe that warrants some complexity?

Meson generates a 'ninja test' target, and has a mesontest which I assume is
similar to CTest, but I've never used mesontest or CTest tbh, so I can't comment
too much about either.

> > 3) recursive meson files, flat ninja file.
> 
> IIRC you would also get the same with CMake if you target Ninja.

That's fair.

> > 
> > I've never had to use gitattributes for anything, are you thinking for 
> > setting
> > export-ignore and export-subst?
> 
> Yep. AFAICT we have several files which aren't distributed if you do "make
> dist". Those would need to be excluded from a tarball built with git archive 
> as
> well. AFAIK that's done through having .gitattributes files in the tree.

I'll have a look at what ends up in the dist-tarball and what ends up in a
git-archive tarbal too. Thanks for pointing that out.

> Anyway, I don't want to bikeshed here, so I'll be silent as long as any 
> possible
> future build system doesn't download stuff behind my back.
> 
> Thanks for your reply!
> 
> Cheers,
> Kai

Thanks for your reply Kai, I hadn't even noticed wrap, so at the very least it's
good to see that's there, and I'll be sure to add a note to the README that we
don't use wrap on Linux, BSD and similar.

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] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov  wrote:
> On 21 March 2017 at 18:06, Matt Turner  wrote:
>> (1) Non-recursive automake is necessary for parallel build performance
> Fully agree
>
>> (2) Non-recursive automake is intractably unmaintainable for
>> sufficiently large projects
> Not sure I agree here. Do the src/intel/Makefile* files, seem unmaintainable ?

Not by itself.

src/intel only accounts for 70 thousand lines of code. Mesa is 1.25 million.

>> (3) Mesa is a sufficiently large project
>>
> Again - fully agree.
>
>> Therefore using automake will be either bad for parallel build
>> performance, unmaintainable, or both.
>>
>> Meson aims to be a build system actually capable of replacing
>> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
>> cleaner domain specific language for writing the build rules, while
>> generating non-recursive ninja build files. It does not use libtool.
>> It supports Windows. It supports cross compilation.
>>
> Does it support, Darwin/MacOSX, Cygwin, any of the BSDs, Solaris (and
> alike) platforms,

Its website says "Linux, OSX, Windows, Gcc, Clang, Visual Studio and
others". I see Meson in FreeBSD's ports. It's written in python, so I
expect it will support any of the platforms we care about.

> How about Android - Android.mk or Blueprint.

We have gone over this.

> Does it have "dist", "check", "distcheck" or less commonly used

Our thinking is that by switching to a build system that doesn't
require large amounts of generated code (configure, Makefile.in, etc),
we will stop shipping the code generated by the build system in the
tarballs (which would just be created by git archive). None of that is
set in stone.

> "ctags" "cscope"  targets ?

I don't know.

>> And it has momentum: libepoxy already has a Meson build system. Others
>> in the X.Org community are experimenting with it for libinput, Wayland
>> and Weston, and the xserver.
>>
>> All of that makes Meson very compelling.
> That's the thing - I'm never said that it's _not_ a very compelling project.
> I'm saying that it's not there yet - mostly due to the list above.

Perfect. Since no one claimed it's "there yet" there is nothing to
disagree about.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov 
wrote:

> On 21 March 2017 at 18:06, Matt Turner  wrote:
> > On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov 
> wrote:
> >> On 21 March 2017 at 15:57, Matt Turner  wrote:
> >>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
>  On 20 March 2017 at 18:30, Matt Turner  wrote:
> > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> >> Seems like we ended up all over the place, so let me try afresh.
> >>
> >> Above all:
> >>  - Saying "I don't care" about your users is arrogant - let us _not_
> >> do that, please ?
> >
> > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > arbitrary restrictions caused including Mesa in its core: 10+ year
> old
> > GCC,
>  IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>  wasn't OpenBSD to blame here ;-)
> 
> > non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> > NetBSD keep Mesa as part of the core operating system, and as such
> > don't suffer from these problems.
> >
> > For better or worse, they have made their choices and they get to
> live
> > with them. We are not beholden to them.
> >
>  Overall this hunk seems misplaced. I go agree that we should not cater
>  for all their needs. At the same time, intentionally, breaking things
>  while we all can coexist is very strange.
> 
> >> Even Linux distribution maintainers have responded that "upstream
> does
> >> not care us", which is indicative that we should be more careful
> what
> >> we say.
> >
> > Citation needed.
> >
>  https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>  couple of instances where I've been contacted in private.
> 
> >> For the rest - we're dealing with two orthogonal issues here:
> >>
> >> * Multiple build systems
> >> I believe we'll all agree that I might be the person who's been in
> all
> >> the build systems the most.
> >> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that
> yet:
> >
> > No one is advocating dropping all of the existing build systems yet.
> >
> > This patch is an RFC for a smaller project to start the discussion
> about Mesa.
> >
> >>  - [currently] there is no viable solution for Android
> >
> > Acknowledged. Dylan is going to see if this is something that can be
> > solved in upstream Meson.
> >
>  I would suggest checking with Android people as well, as Meson.
>  There's some plans on moving to yet another build system - Blueprint.
> 
> >>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> >> write one from scratch, IIRC Solaris/FreeBSD and others are in
> similar
> >> boat.
> >
> > Solaris is a closed source operating system whose developers do not
> > contribute to the project. We do not need to base our decisions on
> > them.
> >
> > Mesa is not subject to ridiculous requirements (like in the case of
> > OpenBSD) in FreeBSD and NetBSD.
>  Again - not a requirement, but coexistence.
> 
> > Mesa depends on gmake in FreeBSD's
> > ports, for instance.
> >
>  That amongst others is a bug in their packaging.
> >>>
> >>> That is not even remotely the point.
> >>>
> >>> My point is that they are not subjecting themselves (and us by
> >>> extension, since you want to let them) to such ridiculous
> >>> requirements.
> >>>
> >> I will kindly ask you to keep these adjectives outside of what aims to
> >> be (?) technical discussion.
> >
> > Huh?
> >
> > Didn't you call us arrogant in this very thread? Didn't you suggest
> > we're immature?
> >
> Should I was unclear previously - I'm not trying to belittle, insult
> or otherwise offend your/anyone's contribution or input.
>
> I'm hoping to have a technical discussion, which does not have phrases
> such as "slow as mud" "i don't care", "X is ridiculous" and friends.
>
> >> And on your question - 50-100 lines worth of compatibility changes
> >> across a 6.5kloc of build system is not that unreasonable, right ?
> >
> > You're still not understanding my point.
> >
> > So I don't think any of this is true.
> >
>  I'd suggest giving it a try then - grab a non-GNU make, a release
>  tarball and let me know if you spot any issues.
> 
> >> These projects have been getting closer to upstream and "forcing"
> the
> >> extra obstacle is effectively giving them the middle finger.
> >
> > No. Requiring us to compile with a 10 year old GCC is giving a
> middle finger.
> >
>  Can we stop with the GCC thing ? Can we point to a place where we want
>  to use feature A introduced with GCC B and we don't 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 18:06, Matt Turner  wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov  
> wrote:
>> On 21 March 2017 at 15:57, Matt Turner  wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
>>> wrote:
 On 20 March 2017 at 18:30, Matt Turner  wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> wrote:
>> Seems like we ended up all over the place, so let me try afresh.
>>
>> Above all:
>>  - Saying "I don't care" about your users is arrogant - let us _not_
>> do that, please ?
>
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC,
 IIRC Brian was using old MinGW GCC, which was one of the blockers - it
 wasn't OpenBSD to blame here ;-)

> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
>
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.
>
 Overall this hunk seems misplaced. I go agree that we should not cater
 for all their needs. At the same time, intentionally, breaking things
 while we all can coexist is very strange.

>> Even Linux distribution maintainers have responded that "upstream does
>> not care us", which is indicative that we should be more careful what
>> we say.
>
> Citation needed.
>
 https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
 couple of instances where I've been contacted in private.

>> For the rest - we're dealing with two orthogonal issues here:
>>
>> * Multiple build systems
>> I believe we'll all agree that I might be the person who's been in all
>> the build systems the most.
>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>
> No one is advocating dropping all of the existing build systems yet.
>
> This patch is an RFC for a smaller project to start the discussion about 
> Mesa.
>
>>  - [currently] there is no viable solution for Android
>
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
>
 I would suggest checking with Android people as well, as Meson.
 There's some plans on moving to yet another build system - Blueprint.

>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> boat.
>
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.
>
> Mesa is not subject to ridiculous requirements (like in the case of
> OpenBSD) in FreeBSD and NetBSD.
 Again - not a requirement, but coexistence.

> Mesa depends on gmake in FreeBSD's
> ports, for instance.
>
 That amongst others is a bug in their packaging.
>>>
>>> That is not even remotely the point.
>>>
>>> My point is that they are not subjecting themselves (and us by
>>> extension, since you want to let them) to such ridiculous
>>> requirements.
>>>
>> I will kindly ask you to keep these adjectives outside of what aims to
>> be (?) technical discussion.
>
> Huh?
>
> Didn't you call us arrogant in this very thread? Didn't you suggest
> we're immature?
>
Should I was unclear previously - I'm not trying to belittle, insult
or otherwise offend your/anyone's contribution or input.

I'm hoping to have a technical discussion, which does not have phrases
such as "slow as mud" "i don't care", "X is ridiculous" and friends.

>> And on your question - 50-100 lines worth of compatibility changes
>> across a 6.5kloc of build system is not that unreasonable, right ?
>
> You're still not understanding my point.
>
> So I don't think any of this is true.
>
 I'd suggest giving it a try then - grab a non-GNU make, a release
 tarball and let me know if you spot any issues.

>> These projects have been getting closer to upstream and "forcing" the
>> extra obstacle is effectively giving them the middle finger.
>
> No. Requiring us to compile with a 10 year old GCC is giving a middle 
> finger.
>
 Can we stop with the GCC thing ? Can we point to a place where we want
 to use feature A introduced with GCC B and we don't ?
>>>
>>> Are you freaking serious?!
>>>
>>> This happens *all* the time. It happened like two days ago with commit
>>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>>> happened at least once in the previous month, and every month before
>>> that.
>>>
>> Considering none of the ANV 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 21.03.2017 18:34:
> Quoting Kai Wasserbäch (2017-03-21 09:50:52)
>> I've just a few points, since I'm not too enthused by the prospect of having 
>> to
>> deal with yet another build system with yet another slightly different 
>> syntax.
>> But ultimately this is only a "my 2 cents" e-mail, since others are way 
>> deeper
>> involved with Mesa and their opinion is what matters in the end. Anyway, here
>> goes nothing.
>>
>> This might be a dumb question but isn't Meson (through wrap files) one of the
>> build systems that download crap from all over the internet silently? Ie. 
>> making
>> a packager's/distribution's life hell? There is
>> 
>> but that seems to imply a silent fallback to downloading stuff. I would 
>> rather
>> have a configure step that fails if a dependency is not met instead of 
>> building
>> something that can't be distributed. Or is there a magic 
>> "--distribution-build"
>> flag? If there isn't I would rather see a switch to CMake (as others have
>> pointed out in this thread: many projects in the vicinity of Mesa already use
>> CMake), but I get that there's a lot of hate for CMake (even though the Meson
>> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
>> would be unlikely.
> 
> I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
> aimed at windows and osx, where bundling is the norm, and not Linux and the 
> BSDs
> where it's not. What I would expect if the windows guys wanted to use wrap is
> that we would have something like this:
> 
> if host_machine.system() != 'windows'
> dep_zlib = dependency('zlib', version : '>1.0.0')
> else
> subproj_zlib = subproject('zlib')
> dep_zlib = subproj_zlib.get_variable('zlib_dep')
> endif
> 
> Which would make the dependency a hard requirement for non-windows system 
> (i.e.
> the configure fails if zlib isn't found *except* on windows), and windows 
> could
> fall back to wraps.
> 
> I have no plans to implement wrap for mesa in the port I would do, and would 
> NAK
> any patches that used wrap on Linux or BSD. The windows devs can make their 
> own
> choice on how to handle dependencies (I have no idea what their development
> environment looks like and don't want to make that choice for them). I agree
> with you it's not the way that Linux or BSD works, we have competent package
> management solutions without the need to automatically download sources.

I hope the rest of the Mesa project would follow such a rule. Because if there's
something I absolutely hate about all those "new" build systems, then it's their
tendency to just download stuff and build/include that. This seems to have risen
with Node and now spread into Rust and other parts of the FLOSS eco-system.

> As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
> and cmake are the difference between python and perl, there may be some
> superficial similarities, but they are *not* the same. One of the things I'll
> reiterate that impressed me the most about meson is that it's syntax is 
> simple,
> not Turring-complete, and opinionated.
> 
> In fact, piglit is the best reason not not use cmake I can come up with. There
> is an (admittedly clever) hack to allow building tests for each of the API's
> supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
> each API, which means you can't put things in the tests directory that can 
> only
> be run once. Every time I try to make changes to the Cmake I spend about an 
> hour
> trying to figure out why some code I've implemented doesn't work, only to
> remember that. Build systems aren't programming languages, they shouldn't be
> interesting, they should be declarative; cmake is a full scripting language 
> with
> enough warts to make bash look cuddly.

Hm, I have written a lot of CMakeFiles.txt and so far I've always been rather
happy with them. Not sure what Piglit is doing though.

>> Dylan Baker wrote on 16.03.2017 22:25:
>>> Why bother, and why would we want this?
>>>
>>> First it's written in python, which means the potential developer base
>>> is massive. And it provides a recursive view for humans, but a
>>> non-recursive view for the system. This is the best of both worlds,
>>> humans can organize the build system in a way that makes sense, and the
>>> machine gets a non-recursive build system. It also uses ninja rather
>>> than make, and ninja is faster than make inherently.
>>
>> Well, CMake (and probably others), see
>> , can use/generate 
>> for
>> ninja too.
> 
> Sure, I think we've gone over this in the rather long thread, ninja is really
> just a "nice to have" since it's faster than make. The real advantages are:
> 1) one build system for linux and windows (reducing from 3 to 2 build systems)

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov  wrote:
> On 21 March 2017 at 15:57, Matt Turner  wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
>> wrote:
>>> On 20 March 2017 at 18:30, Matt Turner  wrote:
 On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
 wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
>  - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?

 Let's be honest, the OpenBSD is subjecting itself to some pretty
 arbitrary restrictions caused including Mesa in its core: 10+ year old
 GCC,
>>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>>> wasn't OpenBSD to blame here ;-)
>>>
 non-GNU Make, and now no Meson. I don't believe either FreeBSD or
 NetBSD keep Mesa as part of the core operating system, and as such
 don't suffer from these problems.

 For better or worse, they have made their choices and they get to live
 with them. We are not beholden to them.

>>> Overall this hunk seems misplaced. I go agree that we should not cater
>>> for all their needs. At the same time, intentionally, breaking things
>>> while we all can coexist is very strange.
>>>
> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.

 Citation needed.

>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>>> couple of instances where I've been contacted in private.
>>>
> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:

 No one is advocating dropping all of the existing build systems yet.

 This patch is an RFC for a smaller project to start the discussion about 
 Mesa.

>  - [currently] there is no viable solution for Android

 Acknowledged. Dylan is going to see if this is something that can be
 solved in upstream Meson.

>>> I would suggest checking with Android people as well, as Meson.
>>> There's some plans on moving to yet another build system - Blueprint.
>>>
>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.

 Solaris is a closed source operating system whose developers do not
 contribute to the project. We do not need to base our decisions on
 them.

 Mesa is not subject to ridiculous requirements (like in the case of
 OpenBSD) in FreeBSD and NetBSD.
>>> Again - not a requirement, but coexistence.
>>>
 Mesa depends on gmake in FreeBSD's
 ports, for instance.

>>> That amongst others is a bug in their packaging.
>>
>> That is not even remotely the point.
>>
>> My point is that they are not subjecting themselves (and us by
>> extension, since you want to let them) to such ridiculous
>> requirements.
>>
> I will kindly ask you to keep these adjectives outside of what aims to
> be (?) technical discussion.

Huh?

Didn't you call us arrogant in this very thread? Didn't you suggest
we're immature?

> And on your question - 50-100 lines worth of compatibility changes
> across a 6.5kloc of build system is not that unreasonable, right ?

You're still not understanding my point.

 So I don't think any of this is true.

>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>>> tarball and let me know if you spot any issues.
>>>
> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.

 No. Requiring us to compile with a 10 year old GCC is giving a middle 
 finger.

>>> Can we stop with the GCC thing ? Can we point to a place where we want
>>> to use feature A introduced with GCC B and we don't ?
>>
>> Are you freaking serious?!
>>
>> This happens *all* the time. It happened like two days ago with commit
>> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
>> happened at least once in the previous month, and every month before
>> that.
>>
> Considering none of the ANV code is built outside of Linux, why you
> guys will restrict yourself is beyond me.

I think you're confused.

> Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.
>
>>> The anonymous unions/structs for example require newer GCC and we use
>>> them extensively. If anything we have the workaround(s) for MSVC's
>>> lack of designated initializers.
>>
>> We actually have
>>
>> if test "x$USE_GNU99" = xyes; then
>> CFLAGS="$CFLAGS 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hi Kai,

Quoting Kai Wasserbäch (2017-03-21 09:50:52)
> Hey Dylan,
> I've just a few points, since I'm not too enthused by the prospect of having 
> to
> deal with yet another build system with yet another slightly different syntax.
> But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
> involved with Mesa and their opinion is what matters in the end. Anyway, here
> goes nothing.
> 
> This might be a dumb question but isn't Meson (through wrap files) one of the
> build systems that download crap from all over the internet silently? Ie. 
> making
> a packager's/distribution's life hell? There is
> 
> but that seems to imply a silent fallback to downloading stuff. I would rather
> have a configure step that fails if a dependency is not met instead of 
> building
> something that can't be distributed. Or is there a magic 
> "--distribution-build"
> flag? If there isn't I would rather see a switch to CMake (as others have
> pointed out in this thread: many projects in the vicinity of Mesa already use
> CMake), but I get that there's a lot of hate for CMake (even though the Meson
> syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
> would be unlikely.

I hadn't even noticed wrap before. Looking at it wraps they seem to be mainly
aimed at windows and osx, where bundling is the norm, and not Linux and the BSDs
where it's not. What I would expect if the windows guys wanted to use wrap is
that we would have something like this:

if host_machine.system() != 'windows'
dep_zlib = dependency('zlib', version : '>1.0.0')
else
subproj_zlib = subproject('zlib')
dep_zlib = subproj_zlib.get_variable('zlib_dep')
endif

Which would make the dependency a hard requirement for non-windows system (i.e.
the configure fails if zlib isn't found *except* on windows), and windows could
fall back to wraps.

I have no plans to implement wrap for mesa in the port I would do, and would NAK
any patches that used wrap on Linux or BSD. The windows devs can make their own
choice on how to handle dependencies (I have no idea what their development
environment looks like and don't want to make that choice for them). I agree
with you it's not the way that Linux or BSD works, we have competent package
management solutions without the need to automatically download sources.

As for cmake. I've written enough cmake in piglit to last me a lifetime, meson
and cmake are the difference between python and perl, there may be some
superficial similarities, but they are *not* the same. One of the things I'll
reiterate that impressed me the most about meson is that it's syntax is simple,
not Turring-complete, and opinionated.

In fact, piglit is the best reason not not use cmake I can come up with. There
is an (admittedly clever) hack to allow building tests for each of the API's
supported (GL, GLES1, and GLES2+). It does this by re-reunning the cmake for
each API, which means you can't put things in the tests directory that can only
be run once. Every time I try to make changes to the Cmake I spend about an hour
trying to figure out why some code I've implemented doesn't work, only to
remember that. Build systems aren't programming languages, they shouldn't be
interesting, they should be declarative; cmake is a full scripting language with
enough warts to make bash look cuddly.

> 
> Dylan Baker wrote on 16.03.2017 22:25:
> > Why bother, and why would we want this?
> > 
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently.
> 
> Well, CMake (and probably others), see
> , can use/generate 
> for
> ninja too.

Sure, I think we've gone over this in the rather long thread, ninja is really
just a "nice to have" since it's faster than make. The real advantages are:
1) one build system for linux and windows (reducing from 3 to 2 build systems)
2) meson much simpler than autotools, scons, or (especially) cmake
3) recursive meson files, flat ninja file.

> 
> > Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> > 
> > What's different about using meson?
> > 
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 21 March 2017 at 15:57, Matt Turner  wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
> wrote:
>> On 20 March 2017 at 18:30, Matt Turner  wrote:
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>>> wrote:
 Seems like we ended up all over the place, so let me try afresh.

 Above all:
  - Saying "I don't care" about your users is arrogant - let us _not_
 do that, please ?
>>>
>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>> GCC,
>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> wasn't OpenBSD to blame here ;-)
>>
>>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>> NetBSD keep Mesa as part of the core operating system, and as such
>>> don't suffer from these problems.
>>>
>>> For better or worse, they have made their choices and they get to live
>>> with them. We are not beholden to them.
>>>
>> Overall this hunk seems misplaced. I go agree that we should not cater
>> for all their needs. At the same time, intentionally, breaking things
>> while we all can coexist is very strange.
>>
 Even Linux distribution maintainers have responded that "upstream does
 not care us", which is indicative that we should be more careful what
 we say.
>>>
>>> Citation needed.
>>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>> couple of instances where I've been contacted in private.
>>
 For the rest - we're dealing with two orthogonal issues here:

 * Multiple build systems
 I believe we'll all agree that I might be the person who's been in all
 the build systems the most.
 Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>>
>>> No one is advocating dropping all of the existing build systems yet.
>>>
>>> This patch is an RFC for a smaller project to start the discussion about 
>>> Mesa.
>>>
  - [currently] there is no viable solution for Android
>>>
>>> Acknowledged. Dylan is going to see if this is something that can be
>>> solved in upstream Meson.
>>>
>> I would suggest checking with Android people as well, as Meson.
>> There's some plans on moving to yet another build system - Blueprint.
>>
  - dropping the Autotools will lead to OpenBSD and NetBSD having to
 write one from scratch, IIRC Solaris/FreeBSD and others are in similar
 boat.
>>>
>>> Solaris is a closed source operating system whose developers do not
>>> contribute to the project. We do not need to base our decisions on
>>> them.
>>>
>>> Mesa is not subject to ridiculous requirements (like in the case of
>>> OpenBSD) in FreeBSD and NetBSD.
>> Again - not a requirement, but coexistence.
>>
>>> Mesa depends on gmake in FreeBSD's
>>> ports, for instance.
>>>
>> That amongst others is a bug in their packaging.
>
> That is not even remotely the point.
>
> My point is that they are not subjecting themselves (and us by
> extension, since you want to let them) to such ridiculous
> requirements.
>
I will kindly ask you to keep these adjectives outside of what aims to
be (?) technical discussion.

And on your question - 50-100 lines worth of compatibility changes
across a 6.5kloc of build system is not that unreasonable, right ?

>>> So I don't think any of this is true.
>>>
>> I'd suggest giving it a try then - grab a non-GNU make, a release
>> tarball and let me know if you spot any issues.
>>
 These projects have been getting closer to upstream and "forcing" the
 extra obstacle is effectively giving them the middle finger.
>>>
>>> No. Requiring us to compile with a 10 year old GCC is giving a middle 
>>> finger.
>>>
>> Can we stop with the GCC thing ? Can we point to a place where we want
>> to use feature A introduced with GCC B and we don't ?
>
> Are you freaking serious?!
>
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.
>
Considering none of the ANV code is built outside of Linux, why you
guys will restrict yourself is beyond me.
Nine requires GCC 4.6 and Clover GCC 4.7 for a long time.

>> The anonymous unions/structs for example require newer GCC and we use
>> them extensively. If anything we have the workaround(s) for MSVC's
>> lack of designated initializers.
>
> We actually have
>
> if test "x$USE_GNU99" = xyes; then
> CFLAGS="$CFLAGS -std=gnu99"
> else
> CFLAGS="$CFLAGS -std=c99"
> fi
>
> in configure.ac to work around gcc-4.4 incompatibilities.
>
5-10 lines of configure code is not that much of a burden, right ?

>> Not to mention that some/many of the restrictions are imposed by very
>> older enterprise linuxes.
>
> which eventually go out of support and those requirements disappear.
> 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kai Wasserbäch]

Hey Dylan,
I've just a few points, since I'm not too enthused by the prospect of having to
deal with yet another build system with yet another slightly different syntax.
But ultimately this is only a "my 2 cents" e-mail, since others are way deeper
involved with Mesa and their opinion is what matters in the end. Anyway, here
goes nothing.

This might be a dumb question but isn't Meson (through wrap files) one of the
build systems that download crap from all over the internet silently? Ie. making
a packager's/distribution's life hell? There is

but that seems to imply a silent fallback to downloading stuff. I would rather
have a configure step that fails if a dependency is not met instead of building
something that can't be distributed. Or is there a magic "--distribution-build"
flag? If there isn't I would rather see a switch to CMake (as others have
pointed out in this thread: many projects in the vicinity of Mesa already use
CMake), but I get that there's a lot of hate for CMake (even though the Meson
syntax looks a lot like CMake, so I'm not really sure why?) and such a switch
would be unlikely.

Dylan Baker wrote on 16.03.2017 22:25:
> Why bother, and why would we want this?
> 
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently.

Well, CMake (and probably others), see
, can use/generate for
ninja too.

> Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
> 
> What's different about using meson?
> 
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?

Nothing against git archive, but you then would need to maintain .gitattributes
in addition to the build system input files, correct? Right now the distribution
rules are just in the Makefile.in files, making them more visible and less
easily forgotten.

> [...]

Cheers,
Kai



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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jani Nikula (2017-03-21 07:44:55)
> On Thu, 16 Mar 2017, Dylan Baker  wrote:
> > First it's written in python, [...]
> 
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?

Meson requires python 3.4+, and doesn't support python 2. Python 3.4 was
released in 2012. It's also worth nothing that a couple of us have been working
to get mesa's python scripts python3 compatible, so in the (hopefully) near
future python2 wouldn't be required.

> How does meson handle build file backwards compatibility between meson
> versions? I don't intend to flame, but I've found for some reason many
> python projects don't seem to take this very seriously. Either having
> conditionals in build files to support building with several meson
> versions or always requiring the latest and greatest version would be
> rather annoying.

Meson makes backwards compatible changes, and the version can be queried using
`meson.version()`, which works using meson's version comparison mechanism. I
would say this about meson, it's not a 'python project', it's 'a project written
in python', and they've taken great pains to not expose python in meson, and
reserve the right to reimplement in a different language if python becomes an
issue.


> BR,
> Jani.
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

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] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

I would personally rather have scons and autotools than cmake. I've had the
misfortune of using all three, and cmake is not an improvement in my opinion.

Quoting Grazvydas Ignotas (2017-03-21 08:13:31)
> It might make sense to give more attention to cmake just because many
> mesa-related projects are already using it: llvm, piglit, vulkan
> loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
> and windows, but everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
> 
> Gražvydas
> 
> On Tue, Mar 21, 2017 at 4:44 PM, Jani Nikula
>  wrote:
> > On Thu, 16 Mar 2017, Dylan Baker  wrote:
> >> First it's written in python, [...]
> >
> > How does meson handle python 2 vs. 3? How do you avoid issues in the
> > build files wrt this? On Debian meson seems to depend on python 3, so
> > are they fully python 3?
> >
> > How does meson handle build file backwards compatibility between meson
> > versions? I don't intend to flame, but I've found for some reason many
> > python projects don't seem to take this very seriously. Either having
> > conditionals in build files to support building with several meson
> > versions or always requiring the latest and greatest version would be
> > rather annoying.
> >
> >
> > BR,
> > Jani.
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 10:10 PM, Jonathan Gray  wrote:
> On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> wrote:
>> > Seems like we ended up all over the place, so let me try afresh.
>> >
>> > Above all:
>> >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>
> This isn't a situation like OpenSSH where people explicitly go out of
> their way to provide support for and test multiple systems and add
> support for horrible things like PAM.  It is more along the lines of
> considering integrating patches sent by others to make code build.

I think we (and you) have been able to deal with compiler problems
reasonably well. I don't have a particular problem taking patches for
things like that. GCC is just an example of the problem.

My core point is that OpenBSD has made choices to build Mesa with
tools and versions no one else uses. If we want to add a new build
dependency not in OpenBSD's core, I don't think it's fair for
OpenBSD's choices prevent us from moving forward.

>> > Even Linux distribution maintainers have responded that "upstream does
>> > not care us", which is indicative that we should be more careful what
>> > we say.
>>
>> Citation needed.
>>
>> > For the rest - we're dealing with two orthogonal issues here:
>> >
>> > * Multiple build systems
>> > I believe we'll all agree that I might be the person who's been in all
>> > the build systems the most.
>> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about 
>> Mesa.
>>
>> >  - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
>> >  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> > boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>
> So Mesa will remove support for libglvnd then?  I don't see a lot of
> open source non-Mesa alternatives for libGL.

Huh? libglvnd is free software.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 10:00 PM, Jonathan Gray  wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner  wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> > > wrote:
>> > > > Seems like we ended up all over the place, so let me try afresh.
>> > > >
>> > > > Above all:
>> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
>> > > > do that, please ?
>> > >
>> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
>> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
>> > > GCC,
>> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> > wasn't OpenBSD to blame here ;-)
>>
>> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
>> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>>
>> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
>> rather not go through the upgrade hassle if I don't have to."
>>
>> Followed by Jose "We're internally building and shipping Mesa compiled with
>> GCC 4.4 (more specifically 4.4.3).
>>
>> It's fine if you require GCC 4.8 on automake, but please leave support
>> for GCC 4.4.x in SCons."
>>
>> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
>> various features backported, from what I understand Mesa would not build on
>> a real GCC 4.2 release and we should not be using it as a min version. IMO
>> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
>> the min GCC version.
>>
>> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
>> deal with it if we move on.
>
> I would like to see Mesa test features it uses in configure rather than
> arbitary versions that are what a certain linux distribution ships with.
> The zlib change for instance didn't reference any specific problems with
> older versions or interfaces required from newer versions.

How can we reasonably do that? In the context of the patch you inlined
-- what would make us believe designated initializers aren't available
in some version of GCC and we should test for it? They're just a C99
feature AFAIK.

And what would we do if we check and they're not available? Presumably
you're not advocating for #ifdef'ing and having two pieces of the same
code.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  wrote:
> On 20 March 2017 at 18:30, Matt Turner  wrote:
>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>> wrote:
>>> Seems like we ended up all over the place, so let me try afresh.
>>>
>>> Above all:
>>>  - Saying "I don't care" about your users is arrogant - let us _not_
>>> do that, please ?
>>
>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>> GCC,
> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> wasn't OpenBSD to blame here ;-)
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>> NetBSD keep Mesa as part of the core operating system, and as such
>> don't suffer from these problems.
>>
>> For better or worse, they have made their choices and they get to live
>> with them. We are not beholden to them.
>>
> Overall this hunk seems misplaced. I go agree that we should not cater
> for all their needs. At the same time, intentionally, breaking things
> while we all can coexist is very strange.
>
>>> Even Linux distribution maintainers have responded that "upstream does
>>> not care us", which is indicative that we should be more careful what
>>> we say.
>>
>> Citation needed.
>>
> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
> couple of instances where I've been contacted in private.
>
>>> For the rest - we're dealing with two orthogonal issues here:
>>>
>>> * Multiple build systems
>>> I believe we'll all agree that I might be the person who's been in all
>>> the build systems the most.
>>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>>
>> No one is advocating dropping all of the existing build systems yet.
>>
>> This patch is an RFC for a smaller project to start the discussion about 
>> Mesa.
>>
>>>  - [currently] there is no viable solution for Android
>>
>> Acknowledged. Dylan is going to see if this is something that can be
>> solved in upstream Meson.
>>
> I would suggest checking with Android people as well, as Meson.
> There's some plans on moving to yet another build system - Blueprint.
>
>>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>>> boat.
>>
>> Solaris is a closed source operating system whose developers do not
>> contribute to the project. We do not need to base our decisions on
>> them.
>>
>> Mesa is not subject to ridiculous requirements (like in the case of
>> OpenBSD) in FreeBSD and NetBSD.
> Again - not a requirement, but coexistence.
>
>> Mesa depends on gmake in FreeBSD's
>> ports, for instance.
>>
> That amongst others is a bug in their packaging.

That is not even remotely the point.

My point is that they are not subjecting themselves (and us by
extension, since you want to let them) to such ridiculous
requirements.

>> So I don't think any of this is true.
>>
> I'd suggest giving it a try then - grab a non-GNU make, a release
> tarball and let me know if you spot any issues.
>
>>> These projects have been getting closer to upstream and "forcing" the
>>> extra obstacle is effectively giving them the middle finger.
>>
>> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>>
> Can we stop with the GCC thing ? Can we point to a place where we want
> to use feature A introduced with GCC B and we don't ?

Are you freaking serious?!

This happens *all* the time. It happened like two days ago with commit
28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
happened at least once in the previous month, and every month before
that.

> The anonymous unions/structs for example require newer GCC and we use
> them extensively. If anything we have the workaround(s) for MSVC's
> lack of designated initializers.

We actually have

if test "x$USE_GNU99" = xyes; then
CFLAGS="$CFLAGS -std=gnu99"
else
CFLAGS="$CFLAGS -std=c99"
fi

in configure.ac to work around gcc-4.4 incompatibilities.

> Not to mention that some/many of the restrictions are imposed by very
> older enterprise linuxes.

which eventually go out of support and those requirements disappear.
Unlike OpenBSD's insistence on using the last GPLv2 GCC.

>>> * Slow build times
>>> Before we jump into "the next cool thing", let us properly utilise
>>> what we have at the moment.
>>
>> It cannot be properly utilized. There is a patch on the list *today*
>> that is attempting to workaround the *design* of libtool. It's an
>> issue that's existed... since libtool?
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=58664
>> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>>
> Yes design is ..., but I'm talking about utilising all the X cores on 
> $platform.
>
>>>  - I've asked multiple times about numbers behind those "let's make
>>> the build faster" 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Ilia Mirkin]

On Tue, Mar 21, 2017 at 11:13 AM, Grazvydas Ignotas  wrote:
> everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.

Or they could be contributing to mesa because it's the last project
with a sane build system.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Grazvydas Ignotas]

It might make sense to give more attention to cmake just because many
mesa-related projects are already using it: llvm, piglit, vulkan
loader and demos, mesa-demos, etc. Not sure how well it supports BSDs
and windows, but everyone building graphics stacks or contributing to
mesa should already be comfortable with cmake thanks to piglit and
llvm, which might not be the case for meson.

Gražvydas

On Tue, Mar 21, 2017 at 4:44 PM, Jani Nikula
 wrote:
> On Thu, 16 Mar 2017, Dylan Baker  wrote:
>> First it's written in python, [...]
>
> How does meson handle python 2 vs. 3? How do you avoid issues in the
> build files wrt this? On Debian meson seems to depend on python 3, so
> are they fully python 3?
>
> How does meson handle build file backwards compatibility between meson
> versions? I don't intend to flame, but I've found for some reason many
> python projects don't seem to take this very seriously. Either having
> conditionals in build files to support building with several meson
> versions or always requiring the latest and greatest version would be
> rather annoying.
>
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jani Nikula]

On Thu, 16 Mar 2017, Dylan Baker  wrote:
> First it's written in python, [...]

How does meson handle python 2 vs. 3? How do you avoid issues in the
build files wrt this? On Debian meson seems to depend on python 3, so
are they fully python 3?

How does meson handle build file backwards compatibility between meson
versions? I don't intend to flame, but I've found for some reason many
python projects don't seem to take this very seriously. Either having
conditionals in build files to support building with several meson
versions or always requiring the latest and greatest version would be
rather annoying.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> wrote:
> > Seems like we ended up all over the place, so let me try afresh.
> >
> > Above all:
> >  - Saying "I don't care" about your users is arrogant - let us _not_
> > do that, please ?
> 
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
> 
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.

This isn't a situation like OpenSSH where people explicitly go out of
their way to provide support for and test multiple systems and add
support for horrible things like PAM.  It is more along the lines of
considering integrating patches sent by others to make code build.

> 
> > Even Linux distribution maintainers have responded that "upstream does
> > not care us", which is indicative that we should be more careful what
> > we say.
> 
> Citation needed.
> 
> > For the rest - we're dealing with two orthogonal issues here:
> >
> > * Multiple build systems
> > I believe we'll all agree that I might be the person who's been in all
> > the build systems the most.
> > Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
> 
> No one is advocating dropping all of the existing build systems yet.
> 
> This patch is an RFC for a smaller project to start the discussion about Mesa.
> 
> >  - [currently] there is no viable solution for Android
> 
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
> 
> >  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> > write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> > boat.
> 
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.

So Mesa will remove support for libglvnd then?  I don't see a lot of
open source non-Mesa alternatives for libGL.

Oh and the mingw, windows and macos support can go as well, great!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
> 
> 
> On 21/03/17 06:39, Emil Velikov wrote:
> > On 20 March 2017 at 18:30, Matt Turner  wrote:
> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> > > wrote:
> > > > Seems like we ended up all over the place, so let me try afresh.
> > > > 
> > > > Above all:
> > > >  - Saying "I don't care" about your users is arrogant - let us _not_
> > > > do that, please ?
> > > 
> > > Let's be honest, the OpenBSD is subjecting itself to some pretty
> > > arbitrary restrictions caused including Mesa in its core: 10+ year old
> > > GCC,
> > IIRC Brian was using old MinGW GCC, which was one of the blockers - it
> > wasn't OpenBSD to blame here ;-)
> 
> Sorry Emil I probably wasn't clear in our discussion. I sent out patches to
> switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
> 
> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> rather not go through the upgrade hassle if I don't have to."
> 
> Followed by Jose "We're internally building and shipping Mesa compiled with
> GCC 4.4 (more specifically 4.4.3).
> 
> It's fine if you require GCC 4.8 on automake, but please leave support
> for GCC 4.4.x in SCons."
> 
> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> various features backported, from what I understand Mesa would not build on
> a real GCC 4.2 release and we should not be using it as a min version. IMO
> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> the min GCC version.
> 
> I believe Jonathan would like us to stick with 4.2 as min but is prepared to
> deal with it if we move on.

I would like to see Mesa test features it uses in configure rather than
arbitary versions that are what a certain linux distribution ships with.
The zlib change for instance didn't reference any specific problems with
older versions or interfaces required from newer versions.

We have one platform using clang/lld now (arm64) and are likely to move
others in future where possible.  libtool has to be patched and the Mesa
configure script regenerated to make this work or Mesa won't build due
to libtool.m4 looking for specific strings in ld -v produced by bfd
binutils or gold...

And yes if you change the configure script to check for a newer version
I'll revert it locally like I did with the zlib one.

As I get the impression no one cares about patches for older GCC I've
not being sending them to the list, ie

commit d3d340d6026e516cc405a2eb1d925a7a7a467480
Author: Jonathan Gray 
Date:   Thu Mar 16 00:30:07 2017 +1100

i965: don't use designated array initialisation

Don't use a form of designated array initialisation that breaks gcc 4.2.1.

compiler/brw_vec4_gs_visitor.cpp:589: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:590: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:591: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:592: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:593: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:594: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:595: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:596: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:597: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:598: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:599: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:600: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:601: error: expected primary-expression 
before '[' token
compiler/brw_vec4_gs_visitor.cpp:602: error: expected primary-expression 
before '[' token

Signed-off-by: Jonathan Gray 

diff --git a/src/intel/compiler/brw_vec4_gs_visitor.cpp 
b/src/intel/compiler/brw_vec4_gs_visitor.cpp
index 4a8b5be30e..e7a502306e 100644
--- a/src/intel/compiler/brw_vec4_gs_visitor.cpp
+++ b/src/intel/compiler/brw_vec4_gs_visitor.cpp
@@ -585,23 +585,6 @@ vec4_gs_visitor::gs_end_primitive()
emit(OR(dst_reg(this->control_data_bits), this->control_data_bits, mask));
 }
 
-static const GLuint gl_prim_to_hw_prim[GL_TRIANGLE_STRIP_ADJACENCY+1] = {
-   [GL_POINTS] =_3DPRIM_POINTLIST,
-   [GL_LINES] = _3DPRIM_LINELIST,
-   [GL_LINE_LOOP] = _3DPRIM_LINELOOP,
-   [GL_LINE_STRIP] = _3DPRIM_LINESTRIP,
-   [GL_TRIANGLES] = _3DPRIM_TRILIST,
-   [GL_TRIANGLE_STRIP] = _3DPRIM_TRISTRIP,
-   [GL_TRIANGLE_FAN] = _3DPRIM_TRIFAN,
-   [GL_QUADS] = _3DPRIM_QUADLIST,
-   [GL_QUAD_STRIP] = _3DPRIM_QUADSTRIP,
-   

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On Mon, Mar 20, 2017 at 2:28 PM, Timothy Arceri 
wrote:

>
>
> On 21/03/17 06:39, Emil Velikov wrote:
>
>> On 20 March 2017 at 18:30, Matt Turner  wrote:
>>
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov 
>>> wrote:
>>>
 Seems like we ended up all over the place, so let me try afresh.

 Above all:
  - Saying "I don't care" about your users is arrogant - let us _not_
 do that, please ?

>>>
>>> Let's be honest, the OpenBSD is subjecting itself to some pretty
>>> arbitrary restrictions caused including Mesa in its core: 10+ year old
>>> GCC,
>>>
>> IIRC Brian was using old MinGW GCC, which was one of the blockers - it
>> wasn't OpenBSD to blame here ;-)
>>
>
> Sorry Emil I probably wasn't clear in our discussion. I sent out patches
> to switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].
>
> Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. I'd
> rather not go through the upgrade hassle if I don't have to."
>
> Followed by Jose "We're internally building and shipping Mesa compiled
> with GCC 4.4 (more specifically 4.4.3).
>
> It's fine if you require GCC 4.8 on automake, but please leave support
> for GCC 4.4.x in SCons."
>
> By this point I got bored and moved on. But OpenBSDs GCC is a fork with
> various features backported, from what I understand Mesa would not build on
> a real GCC 4.2 release and we should not be using it as a min version. IMO
> if OpenBSD want to maintain a GCC fork they can handle a patch to downgrade
> the min GCC version.
>
> I believe Jonathan would like us to stick with 4.2 as min but is prepared
> to deal with it if we move on.
>
> [1] https://patchwork.freedesktop.org/patch/109094/
>
>
>
>> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
>>> NetBSD keep Mesa as part of the core operating system, and as such
>>> don't suffer from these problems.
>>>
>>> For better or worse, they have made their choices and they get to live
>>> with them. We are not beholden to them.
>>>
>>> Overall this hunk seems misplaced. I go agree that we should not cater
>> for all their needs. At the same time, intentionally, breaking things
>> while we all can coexist is very strange.
>>
>
We're not trying to "break things".  The objective is to substantially
simplify maintenance of our already very large and sprawling project.  If
the best way to do that ends up breaking something ancient, that's
something we need to evaluate.  However, "we're breaking X usecase" is not
a slam-dunk argument against it either.


> Even Linux distribution maintainers have responded that "upstream does
 not care us", which is indicative that we should be more careful what
 we say.

>>>
>>> Citation needed.
>>>
>>> https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
>> couple of instances where I've been contacted in private.
>>
>> For the rest - we're dealing with two orthogonal issues here:

 * Multiple build systems
 I believe we'll all agree that I might be the person who's been in all
 the build systems the most.
 Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:

>>>
>>> No one is advocating dropping all of the existing build systems yet.
>>>
>>> This patch is an RFC for a smaller project to start the discussion about
>>> Mesa.
>>>
>>>  - [currently] there is no viable solution for Android

>>>
>>> Acknowledged. Dylan is going to see if this is something that can be
>>> solved in upstream Meson.
>>>
>>> I would suggest checking with Android people as well, as Meson.
>> There's some plans on moving to yet another build system - Blueprint.
>>
>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
 write one from scratch, IIRC Solaris/FreeBSD and others are in similar
 boat.

>>>
>>> Solaris is a closed source operating system whose developers do not
>>> contribute to the project. We do not need to base our decisions on
>>> them.
>>>
>>> Mesa is not subject to ridiculous requirements (like in the case of
>>> OpenBSD) in FreeBSD and NetBSD.
>>>
>> Again - not a requirement, but coexistence.
>>
>> Mesa depends on gmake in FreeBSD's
>>> ports, for instance.
>>>
>>> That amongst others is a bug in their packaging.
>>
>
As is not having clang available when they build mesa.  But we still take
patches to keep it building on 4.2.


> So I don't think any of this is true.
>>>
>>> I'd suggest giving it a try then - grab a non-GNU make, a release
>> tarball and let me know if you spot any issues.
>>
>> These projects have been getting closer to upstream and "forcing" the
 extra obstacle is effectively giving them the middle finger.

>>>
>>> No. Requiring us to compile with a 10 year old GCC is giving a middle
>>> finger.
>>>
>>> Can we stop with the GCC thing ? Can we point to a place where we want
>> to use feature A introduced with GCC B and we don't ?
>>
>
Yes.  I 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Timothy Arceri]

On 21/03/17 06:39, Emil Velikov wrote:

On 20 March 2017 at 18:30, Matt Turner  wrote:

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  wrote:

Seems like we ended up all over the place, so let me try afresh.

Above all:
 - Saying "I don't care" about your users is arrogant - let us _not_
do that, please ?


Let's be honest, the OpenBSD is subjecting itself to some pretty
arbitrary restrictions caused including Mesa in its core: 10+ year old
GCC,

IIRC Brian was using old MinGW GCC, which was one of the blockers - it
wasn't OpenBSD to blame here ;-)


Sorry Emil I probably wasn't clear in our discussion. I sent out patches 
to switch to GCC 4.8 last Sept (I believe this was needed by RHEL6) [1].


Brain jumped in and said "I'm still using the MinGW gcc 4.6 compiler. 
I'd rather not go through the upgrade hassle if I don't have to."


Followed by Jose "We're internally building and shipping Mesa compiled 
with GCC 4.4 (more specifically 4.4.3).


It's fine if you require GCC 4.8 on automake, but please leave support
for GCC 4.4.x in SCons."

By this point I got bored and moved on. But OpenBSDs GCC is a fork with 
various features backported, from what I understand Mesa would not build 
on a real GCC 4.2 release and we should not be using it as a min 
version. IMO if OpenBSD want to maintain a GCC fork they can handle a 
patch to downgrade the min GCC version.


I believe Jonathan would like us to stick with 4.2 as min but is 
prepared to deal with it if we move on.


[1] https://patchwork.freedesktop.org/patch/109094/




non-GNU Make, and now no Meson. I don't believe either FreeBSD or
NetBSD keep Mesa as part of the core operating system, and as such
don't suffer from these problems.

For better or worse, they have made their choices and they get to live
with them. We are not beholden to them.


Overall this hunk seems misplaced. I go agree that we should not cater
for all their needs. At the same time, intentionally, breaking things
while we all can coexist is very strange.


Even Linux distribution maintainers have responded that "upstream does
not care us", which is indicative that we should be more careful what
we say.


Citation needed.


https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
couple of instances where I've been contacted in private.


For the rest - we're dealing with two orthogonal issues here:

* Multiple build systems
I believe we'll all agree that I might be the person who's been in all
the build systems the most.
Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:


No one is advocating dropping all of the existing build systems yet.

This patch is an RFC for a smaller project to start the discussion about Mesa.


 - [currently] there is no viable solution for Android


Acknowledged. Dylan is going to see if this is something that can be
solved in upstream Meson.


I would suggest checking with Android people as well, as Meson.
There's some plans on moving to yet another build system - Blueprint.


 - dropping the Autotools will lead to OpenBSD and NetBSD having to
write one from scratch, IIRC Solaris/FreeBSD and others are in similar
boat.


Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.

Mesa is not subject to ridiculous requirements (like in the case of
OpenBSD) in FreeBSD and NetBSD.

Again - not a requirement, but coexistence.


Mesa depends on gmake in FreeBSD's
ports, for instance.


That amongst others is a bug in their packaging.


So I don't think any of this is true.


I'd suggest giving it a try then - grab a non-GNU make, a release
tarball and let me know if you spot any issues.


These projects have been getting closer to upstream and "forcing" the
extra obstacle is effectively giving them the middle finger.


No. Requiring us to compile with a 10 year old GCC is giving a middle finger.


Can we stop with the GCC thing ? Can we point to a place where we want
to use feature A introduced with GCC B and we don't ?


I think you are missing the point, no-one wants to (should have to) look 
up if features X was in GCC stone-age every-time they want to use 
something. Also as I pointed out when discussing the Zlib min version, 
we should be recommending min versions that are actually regularly 
tested with Mesa. Frankenstein RHEL 6 and OpenBSD libs and tools with 
significant backports should be left to the distros to sort out and do 
their own qa testing/lowering of min versions recommended by Mesa.




The anonymous unions/structs for example require newer GCC and we use
them extensively. If anything we have the workaround(s) for MSVC's
lack of designated initializers.
Not to mention that some/many of the restrictions are imposed by very
older enterprise linuxes.


??? I don't think we do. RHEL 6 is the oldest distro that actually ships 
new version of Mesa and if that were the only concern we 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 20 March 2017 at 18:30, Matt Turner  wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> wrote:
>> Seems like we ended up all over the place, so let me try afresh.
>>
>> Above all:
>>  - Saying "I don't care" about your users is arrogant - let us _not_
>> do that, please ?
>
> Let's be honest, the OpenBSD is subjecting itself to some pretty
> arbitrary restrictions caused including Mesa in its core: 10+ year old
> GCC,
IIRC Brian was using old MinGW GCC, which was one of the blockers - it
wasn't OpenBSD to blame here ;-)

> non-GNU Make, and now no Meson. I don't believe either FreeBSD or
> NetBSD keep Mesa as part of the core operating system, and as such
> don't suffer from these problems.
>
> For better or worse, they have made their choices and they get to live
> with them. We are not beholden to them.
>
Overall this hunk seems misplaced. I go agree that we should not cater
for all their needs. At the same time, intentionally, breaking things
while we all can coexist is very strange.

>> Even Linux distribution maintainers have responded that "upstream does
>> not care us", which is indicative that we should be more careful what
>> we say.
>
> Citation needed.
>
https://bugs.freedesktop.org/show_bug.cgi?id=98487#c4 and there's a
couple of instances where I've been contacted in private.

>> For the rest - we're dealing with two orthogonal issues here:
>>
>> * Multiple build systems
>> I believe we'll all agree that I might be the person who's been in all
>> the build systems the most.
>> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>
> No one is advocating dropping all of the existing build systems yet.
>
> This patch is an RFC for a smaller project to start the discussion about Mesa.
>
>>  - [currently] there is no viable solution for Android
>
> Acknowledged. Dylan is going to see if this is something that can be
> solved in upstream Meson.
>
I would suggest checking with Android people as well, as Meson.
There's some plans on moving to yet another build system - Blueprint.

>>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
>> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
>> boat.
>
> Solaris is a closed source operating system whose developers do not
> contribute to the project. We do not need to base our decisions on
> them.
>
> Mesa is not subject to ridiculous requirements (like in the case of
> OpenBSD) in FreeBSD and NetBSD.
Again - not a requirement, but coexistence.

> Mesa depends on gmake in FreeBSD's
> ports, for instance.
>
That amongst others is a bug in their packaging.

> So I don't think any of this is true.
>
I'd suggest giving it a try then - grab a non-GNU make, a release
tarball and let me know if you spot any issues.

>> These projects have been getting closer to upstream and "forcing" the
>> extra obstacle is effectively giving them the middle finger.
>
> No. Requiring us to compile with a 10 year old GCC is giving a middle finger.
>
Can we stop with the GCC thing ? Can we point to a place where we want
to use feature A introduced with GCC B and we don't ?

The anonymous unions/structs for example require newer GCC and we use
them extensively. If anything we have the workaround(s) for MSVC's
lack of designated initializers.
Not to mention that some/many of the restrictions are imposed by very
older enterprise linuxes.

>> * Slow build times
>> Before we jump into "the next cool thing", let us properly utilise
>> what we have at the moment.
>
> It cannot be properly utilized. There is a patch on the list *today*
> that is attempting to workaround the *design* of libtool. It's an
> issue that's existed... since libtool?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=58664
> https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html
>
Yes design is ..., but I'm talking about utilising all the X cores on $platform.

>>  - I've asked multiple times about numbers behind those "let's make
>> the build faster" patches, but never got any :-\
>
> What patches? The patches in this thread? What is your question?
>
Nearly every time we had a "let's remove this recursive Makefile"
patch I asked "what improvement are we talking about here - how long
does it take before/after this patch to build mesa".
I'm yet to see any numbers :-\

Some cases that come to mind - mapi (gles1/2), glsl, nir and the latest ANV.

>>  - I can improve things but would need access to a fancy XX core
>> system to do rudimentary benchmarks/checks and test patches.
>
> Have you ever seen an autotools build system for a project as complex
> as Mesa that is both non-recursive and comprehensible? I have not, and
> I did a lot of searching. In my opinion, this is an intractable
> problem.
>
Haven't looked at all really - off the top of my head openvswitch comes to mind.
Then again, It's not as extensive as mesa :-\

> ... and with Meson it is tractable. And it doesn't use libtool. And it
> 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Mon, Mar 20, 2017 at 9:55 AM, Emil Velikov  wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
>  - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?
> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.
>
> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
>  - [currently] there is no viable solution for Android
>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.
> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.

my $0.02.. I like autotools mostly because I've dealt with it long
enough to know how to debug when things go wrong, and I dislike
learning new build systems.

That said, a lot of other big userspace projects[1] seem to be
adopting meson so I expect that "learning something new" argument will
fade out.  And if vmwgfx crew comes to the conclusion that they could
replace scons with meson, that would be quite compelling.  (Enough to
justify keeping autotools and meson side-by-side for some time.)  And
if someone could figure out how to make meson work for android builds,
it would be a slam-dunk.

The existing mesa build is complex enough that I doubt it is something
that could be replaced in one fell swoop.  And I'm not really a fan of
living with 12 build systems in the long run.  So probably the best
approach is to try to replace scons with meson, and then see where it
goes from there.

[1] well, I know of gnome and gstreamer.. not sure if/when they will
drop autotools build

BR,
-R


> * Slow build times
> Before we jump into "the next cool thing", let us properly utilise
> what we have at the moment.
>  - I've asked multiple times about numbers behind those "let's make
> the build faster" patches, but never got any :-\
>  - I can improve things but would need access to a fancy XX core
> system to do rudimentary benchmarks/checks and test patches.
>
> Thanks
> Emil
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Matt Turner]

On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  wrote:
> Seems like we ended up all over the place, so let me try afresh.
>
> Above all:
>  - Saying "I don't care" about your users is arrogant - let us _not_
> do that, please ?

Let's be honest, the OpenBSD is subjecting itself to some pretty
arbitrary restrictions caused including Mesa in its core: 10+ year old
GCC, non-GNU Make, and now no Meson. I don't believe either FreeBSD or
NetBSD keep Mesa as part of the core operating system, and as such
don't suffer from these problems.

For better or worse, they have made their choices and they get to live
with them. We are not beholden to them.

> Even Linux distribution maintainers have responded that "upstream does
> not care us", which is indicative that we should be more careful what
> we say.

Citation needed.

> For the rest - we're dealing with two orthogonal issues here:
>
> * Multiple build systems
> I believe we'll all agree that I might be the person who's been in all
> the build systems the most.
> Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:

No one is advocating dropping all of the existing build systems yet.

This patch is an RFC for a smaller project to start the discussion about Mesa.

>  - [currently] there is no viable solution for Android

Acknowledged. Dylan is going to see if this is something that can be
solved in upstream Meson.

>  - dropping the Autotools will lead to OpenBSD and NetBSD having to
> write one from scratch, IIRC Solaris/FreeBSD and others are in similar
> boat.

Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.

Mesa is not subject to ridiculous requirements (like in the case of
OpenBSD) in FreeBSD and NetBSD. Mesa depends on gmake in FreeBSD's
ports, for instance.

So I don't think any of this is true.

> These projects have been getting closer to upstream and "forcing" the
> extra obstacle is effectively giving them the middle finger.

No. Requiring us to compile with a 10 year old GCC is giving a middle finger.

> * Slow build times
> Before we jump into "the next cool thing", let us properly utilise
> what we have at the moment.

It cannot be properly utilized. There is a patch on the list *today*
that is attempting to workaround the *design* of libtool. It's an
issue that's existed... since libtool?

https://bugzilla.redhat.com/show_bug.cgi?id=58664
https://lists.gnu.org/archive/html/libtool/2003-06/msg00068.html

>  - I've asked multiple times about numbers behind those "let's make
> the build faster" patches, but never got any :-\

What patches? The patches in this thread? What is your question?

>  - I can improve things but would need access to a fancy XX core
> system to do rudimentary benchmarks/checks and test patches.

Have you ever seen an autotools build system for a project as complex
as Mesa that is both non-recursive and comprehensible? I have not, and
I did a lot of searching. In my opinion, this is an intractable
problem.

... and with Meson it is tractable. And it doesn't use libtool. And it
can replace at least 2 and maybe all three of our build systems.

Those all seem extremely compelling to me, and I think I've done
enough work on Mesa's build system and on a downstream distribution to
have a valuable opinion on the matter.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

Seems like we ended up all over the place, so let me try afresh.

Above all:
 - Saying "I don't care" about your users is arrogant - let us _not_
do that, please ?
Even Linux distribution maintainers have responded that "upstream does
not care us", which is indicative that we should be more careful what
we say.

For the rest - we're dealing with two orthogonal issues here:

* Multiple build systems
I believe we'll all agree that I might be the person who's been in all
the build systems the most.
Yes I _would_ _love_ to drop it all but we simply _cannot_ do that yet:
 - [currently] there is no viable solution for Android
 - dropping the Autotools will lead to OpenBSD and NetBSD having to
write one from scratch, IIRC Solaris/FreeBSD and others are in similar
boat.
These projects have been getting closer to upstream and "forcing" the
extra obstacle is effectively giving them the middle finger.

* Slow build times
Before we jump into "the next cool thing", let us properly utilise
what we have at the moment.
 - I've asked multiple times about numbers behind those "let's make
the build faster" patches, but never got any :-\
 - I can improve things but would need access to a fancy XX core
system to do rudimentary benchmarks/checks and test patches.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Marek Olšák]

On Fri, Mar 17, 2017 at 5:15 AM, Dylan Baker  wrote:
> Quoting Marek Olšák (2017-03-16 18:53:59)
>> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker  wrote:
>> > Quoting Marek Olšák (2017-03-16 15:36:26)
>> >> Is there a way not to use ninja with meson, because ninja redirects
>> >> all stderr output from gcc to stdout, which breaks many development
>> >> environments that expect errors in stderr?
>> >>
>> >> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> >> wouldn't like any project that I might be involved in to require ninja
>> >> for building.
>> >>
>> >> Marek
>> >
>> > There is no way to use another backend on Linux, and meson will not support
>> > Make. Ninja is a big part of the appeal here, since it is faster than make 
>> > is.
>> > Are there particular tools you know don't work with ninja? It seems like 
>> > in the
>> > 7+ years since ninja came out that someone would have fixed the tools, or 
>> > that
>> > some stream redirection could be used to fix the problem, "ninja 1>&2"?
>>
>> I actually read some thread about it and the conclusion seemed to be
>> that ninja developers don't care. I have no other option than to
>> believe that ninja was made for automated build bots, not for
>> development.
>>
>> Some editors expect that errors and only errors go to stderr and all
>> other garbage info goes to stdout. This is something I can't change.
>>
>> Marek
>
> And I found this: 
> https://groups.google.com/forum/#!topic/ninja-build/4syh2jzXWcI
>
> Which leads me to believe that they would be responsive to a patch, the core
> team just doesn't have a use for it. There is in fact a patch already written
> (linked in that thread), that just needs someone to clean it up and propose it
> for merge.

Well, I guess I can use that. It's still not nice to force some people
to use out-of-tree builds of ninja.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jonathan Gray]

On Thu, Mar 16, 2017 at 09:12:38PM -0700, Dylan Baker wrote:
> quoting jason ekstrand (2017-03-16 19:03:15)
> > on march 16, 2017 5:41:24 pm emil velikov  wrote:
> > > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor 
> > > android :-\
> > 
> > i have trouble bringing myself to care.  the bsds need to stop using 10 
> > year old compilers.  it can be made to work on solaris and bsd if someone 
> > bothered to put a little work into it.  besides, given that large chunks of 
> > gnome are switching they're going to have to make it work some day soon 
> > anyway.
> 
> I decided to check the ports on my freebsd box, it has meson, in fact:
> freebsd: https://svnweb.freebsd.org/ports/head/devel/meson/
> netbsd: http://pkgsrc.se/wip/py-meson
> openbsd: http://ports.su/devel/meson
> 
> The only OS I couldn't find a package for is openindiana (the clostest thing 
> to
> Solaris I could come up with), but there is ninja for Solaris, and meson 
> itself
> is pure python installable via pip, so even there it's not impossible.
> 
> Dylan

OpenBSD has libdrm in the xenocara tree.  If libdrm were to switch
build systems I'd have to maintain a different build system for it.

There are effectively three source trees in OpenBSD.  src with kernel
posix utilities, toolchain etc.  xenocara with xorg, Mesa, fonts.
ports with everything else.  src is self contained, xenocara can
only take dependencies on src and other parts of xenocara.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Marek Olšák (2017-03-16 18:53:59)
> On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker  wrote:
> > Quoting Marek Olšák (2017-03-16 15:36:26)
> >> Is there a way not to use ninja with meson, because ninja redirects
> >> all stderr output from gcc to stdout, which breaks many development
> >> environments that expect errors in stderr?
> >>
> >> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> >> wouldn't like any project that I might be involved in to require ninja
> >> for building.
> >>
> >> Marek
> >
> > There is no way to use another backend on Linux, and meson will not support
> > Make. Ninja is a big part of the appeal here, since it is faster than make 
> > is.
> > Are there particular tools you know don't work with ninja? It seems like in 
> > the
> > 7+ years since ninja came out that someone would have fixed the tools, or 
> > that
> > some stream redirection could be used to fix the problem, "ninja 1>&2"?
> 
> I actually read some thread about it and the conclusion seemed to be
> that ninja developers don't care. I have no other option than to
> believe that ninja was made for automated build bots, not for
> development.
> 
> Some editors expect that errors and only errors go to stderr and all
> other garbage info goes to stdout. This is something I can't change.
> 
> Marek

And I found this: 
https://groups.google.com/forum/#!topic/ninja-build/4syh2jzXWcI

Which leads me to believe that they would be responsive to a patch, the core
team just doesn't have a use for it. There is in fact a patch already written
(linked in that thread), that just needs someone to clean it up and propose it
for merge.

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] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

quoting jason ekstrand (2017-03-16 19:03:15)
> on march 16, 2017 5:41:24 pm emil velikov  wrote:
> > and meson is not a thing on neither bsd(s), solaris (and derivatives) nor 
> > android :-\
> 
> i have trouble bringing myself to care.  the bsds need to stop using 10 
> year old compilers.  it can be made to work on solaris and bsd if someone 
> bothered to put a little work into it.  besides, given that large chunks of 
> gnome are switching they're going to have to make it work some day soon 
> anyway.

I decided to check the ports on my freebsd box, it has meson, in fact:
freebsd: https://svnweb.freebsd.org/ports/head/devel/meson/
netbsd: http://pkgsrc.se/wip/py-meson
openbsd: http://ports.su/devel/meson

The only OS I couldn't find a package for is openindiana (the clostest thing to
Solaris I could come up with), but there is ninja for Solaris, and meson itself
is pure python installable via pip, so even there it's not impossible.

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] [RFC libdrm 0/2] Replace the build system with meson

[Brian Paul]

On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand 
wrote:

> On March 16, 2017 5:41:24 PM Emil Velikov 
> wrote:
>
>> On 17 March 2017 at 00:21, Dylan Baker  wrote:
>>
>>> Hi Emil,
>>>
>>> Quoting Emil Velikov (2017-03-16 16:35:33)
>>>
 While I can see you're impressed by Meson, I would kindly urge you to
 not use it here. As you look closely you can see that one could
 trivially improve the times, yet the biggest thing is that most of the
 code in libdrm must go ;-)

>>>
>>> Perhaps I wasn't clear enough, I don't really expect this to land ever.
>>> I sent
>>> it out more because I'd written it and it works and is a useful
>>> demonstration of
>>> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge
>>> deal :);
>>> but in a larger project, consider that a 4x speedup would be 4 minutes
>>> to 1
>>> minute, and that is a huge difference in time.
>>>
>>> You are still failing to see past your usecase. As said before - if
>> there's any need to improve things say so.
>> Note that you simply cannot apply the 1000x speedup in any situation.
>>
>
> Yes, you can't just linearly apply any scaling factor.  However, when you
> build mesa on a machine with a decent number of threads (I think our build
> machine for the CI system has 32 threads), autotools+make is slow as mud.
> Also, there's very little you can do to speed up configure since it's a
> pile of shell and perl that inherently runs single-threaded and is fairly
> complex due to mesa's complicated dependencies.
>
> As the port is not 1:1 wrt the autoconf one, the performance numbers
 above are comparing apples to oranges.

>>>
>>> I fail to see what I'm missing from meson that would have an effect on
>>> the
>>> times I reported. There are some files that are installed by autoconf
>>> that I
>>> didn't bother to install with meson (because I don't expect this to
>>> land). Since
>>> I didn't time installs, I don't see how it isn't an apples to apples
>>> comparison.
>>>
>>> You already (explicitly) mentioned some differences. Admittedly not a
>> deal breaker.
>>
>> I understand that libdrm is a pessimal case for recursive-make since most
>>> sub folders contain < 5 C files, However, even if you were to flatten
>>> the make
>>> files meson+ninja would still be faster when you consider that meson
>>> configures and builds faster than autotools configures.
>>>
>>> That's correct. If is so concerned - they should slim down the
>> configure.ac ;-)
>>
>
> There are real limits as to what you can do there.
>
> If you/others are unhappy with the build times of libdrm - poke me on
 IRC. I will give you some easy tips on how to improve those.

 You have some good python knowledge - I would kindly urge you to
 improve/rewrite the slow and/or hacky python scripts we have in mesa.
 This is a topic that was mentioned multiple times, and a part where
 everyone will be glad to see some progress.

 Thanks
 Emil

>>>
>>> The real goal here is to do mesa (in case I didn't make that clear
>>> either), and
>>> the advantage for mesa is not just performance, it's that meson supports
>>> visual
>>> studio on windows; which means that we could hopefully not just get
>>> faster
>>> builds, but also replace both autotools and scons with a single build
>>> system.
>>>
>>> Yes that was more than clear. Yet it won't fly, I'm afraid.
>>
>> The VMWare people like their SCons,
>>
>
> How much?  I would really rather the VMWare people speak on behalf of
> VMWare.  Meson is the single best shot we've ever had for replacing both
> with one build system.  I'm sure the VMware people would like to have a
> build system that gets maintained by the community as a whole.
>

Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build system.
Replacing SCons with Meson could be a big deal in that context.  It would
at least involve pulling Meson into our toolchain and rewriting a bunch of
Python code to grok Meson.  I'd have to go off and investigate that to even
see if it's a possibility.  Maybe next week.

-Brian


>
> and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor
>> Android :-\
>>
>
> I have trouble bringing myself to care.  The BSDs need to stop using 10
> year old compilers.  It can be made to work on Solaris and BSD if someone
> bothered to put a little work into it.  Besides, given that large chunks of
> GNOME are switching they're going to have to make it work some day soon
> anyway.
>
> Android is a bit unfortunate.  Mesa is one of the few projects that let's
> the Android people carry their build system in-tree and I would like to
> keep that going if it were practical.  Dylan and I have talked about this a
> decent bit and one potential solution is to see if the meson people would
> accept an Android back-end.  Then we would be 

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On March 16, 2017 5:41:24 PM Emil Velikov  wrote:

On 17 March 2017 at 00:21, Dylan Baker  wrote:

Hi Emil,

Quoting Emil Velikov (2017-03-16 16:35:33)

While I can see you're impressed by Meson, I would kindly urge you to
not use it here. As you look closely you can see that one could
trivially improve the times, yet the biggest thing is that most of the
code in libdrm must go ;-)


Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
it out more because I'd written it and it works and is a useful 
demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge 
deal :);

but in a larger project, consider that a 4x speedup would be 4 minutes to 1
minute, and that is a huge difference in time.


You are still failing to see past your usecase. As said before - if
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any situation.


Yes, you can't just linearly apply any scaling factor.  However, when you 
build mesa on a machine with a decent number of threads (I think our build 
machine for the CI system has 32 threads), autotools+make is slow as mud.  
Also, there's very little you can do to speed up configure since it's a 
pile of shell and perl that inherently runs single-threaded and is fairly 
complex due to mesa's complicated dependencies.



As the port is not 1:1 wrt the autoconf one, the performance numbers
above are comparing apples to oranges.


I fail to see what I'm missing from meson that would have an effect on the
times I reported. There are some files that are installed by autoconf that I
didn't bother to install with meson (because I don't expect this to land). 
Since
I didn't time installs, I don't see how it isn't an apples to apples 
comparison.



You already (explicitly) mentioned some differences. Admittedly not a
deal breaker.


I understand that libdrm is a pessimal case for recursive-make since most
sub folders contain < 5 C files, However, even if you were to flatten the make
files meson+ninja would still be faster when you consider that meson
configures and builds faster than autotools configures.


That's correct. If is so concerned - they should slim down the configure.ac ;-)


There are real limits as to what you can do there.


If you/others are unhappy with the build times of libdrm - poke me on
IRC. I will give you some easy tips on how to improve those.

You have some good python knowledge - I would kindly urge you to
improve/rewrite the slow and/or hacky python scripts we have in mesa.
This is a topic that was mentioned multiple times, and a part where
everyone will be glad to see some progress.

Thanks
Emil


The real goal here is to do mesa (in case I didn't make that clear either), and
the advantage for mesa is not just performance, it's that meson supports visual
studio on windows; which means that we could hopefully not just get faster
builds, but also replace both autotools and scons with a single build system.


Yes that was more than clear. Yet it won't fly, I'm afraid.

The VMWare people like their SCons,


How much?  I would really rather the VMWare people speak on behalf of 
VMWare.  Meson is the single best shot we've ever had for replacing both 
with one build system.  I'm sure the VMware people would like to have a 
build system that gets maintained by the community as a whole.


and Meson is not a thing on neither BSD(s), Solaris (and derivatives) nor 
Android :-\


I have trouble bringing myself to care.  The BSDs need to stop using 10 
year old compilers.  It can be made to work on Solaris and BSD if someone 
bothered to put a little work into it.  Besides, given that large chunks of 
GNOME are switching they're going to have to make it work some day soon anyway.


Android is a bit unfortunate.  Mesa is one of the few projects that let's 
the Android people carry their build system in-tree and I would like to 
keep that going if it were practical.  Dylan and I have talked about this a 
decent bit and one potential solution is to see if the meson people would 
accept an Android back-end.  Then we would be down to a single build system 
(wouldn't that be nice).



If there's something "slow" say what/where and we can improve upon
things. You seems to be rewriting $world because someone sold you that
A is the holy grail.


I don't think that's fair.  No, Meson is not the holy grail but it is the 
closest anyone has yet been able to come to a viable autotools replacement.


Speed is only one aspect to this.  Unifying the Linux and windows builds is 
also a significant advantage.  Also, autotools is objectively terrible and 
having a build system that's modifiable be mere humans without the need for 
hours of pouring over documentation only to find that you did it wrong 
anyway is a definite plus.



___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Marek Olšák]

On Fri, Mar 17, 2017 at 12:11 AM, Dylan Baker  wrote:
> Quoting Marek Olšák (2017-03-16 15:36:26)
>> Is there a way not to use ninja with meson, because ninja redirects
>> all stderr output from gcc to stdout, which breaks many development
>> environments that expect errors in stderr?
>>
>> I'm basically saying that if ninja can't keep gcc errors in stderr, I
>> wouldn't like any project that I might be involved in to require ninja
>> for building.
>>
>> Marek
>
> There is no way to use another backend on Linux, and meson will not support
> Make. Ninja is a big part of the appeal here, since it is faster than make is.
> Are there particular tools you know don't work with ninja? It seems like in 
> the
> 7+ years since ninja came out that someone would have fixed the tools, or that
> some stream redirection could be used to fix the problem, "ninja 1>&2"?

I actually read some thread about it and the conclusion seemed to be
that ninja developers don't care. I have no other option than to
believe that ninja was made for automated build bots, not for
development.

Some editors expect that errors and only errors go to stderr and all
other garbage info goes to stdout. This is something I can't change.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

On 17 March 2017 at 00:21, Dylan Baker  wrote:
> Hi Emil,
>
> Quoting Emil Velikov (2017-03-16 16:35:33)
>> While I can see you're impressed by Meson, I would kindly urge you to
>> not use it here. As you look closely you can see that one could
>> trivially improve the times, yet the biggest thing is that most of the
>> code in libdrm must go ;-)
>
> Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
> it out more because I'd written it and it works and is a useful demonstration 
> of
> meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal 
> :);
> but in a larger project, consider that a 4x speedup would be 4 minutes to 1
> minute, and that is a huge difference in time.
>
You are still failing to see past your usecase. As said before - if
there's any need to improve things say so.
Note that you simply cannot apply the 1000x speedup in any situation.

>>
>> As the port is not 1:1 wrt the autoconf one, the performance numbers
>> above are comparing apples to oranges.
>
> I fail to see what I'm missing from meson that would have an effect on the
> times I reported. There are some files that are installed by autoconf that I
> didn't bother to install with meson (because I don't expect this to land). 
> Since
> I didn't time installs, I don't see how it isn't an apples to apples 
> comparison.
>
You already (explicitly) mentioned some differences. Admittedly not a
deal breaker.

> I understand that libdrm is a pessimal case for recursive-make since most
> sub folders contain < 5 C files, However, even if you were to flatten the make
> files meson+ninja would still be faster when you consider that meson
> configures and builds faster than autotools configures.
>
That's correct. If is so concerned - they should slim down the configure.ac ;-)

>> If you/others are unhappy with the build times of libdrm - poke me on
>> IRC. I will give you some easy tips on how to improve those.
>>
>> You have some good python knowledge - I would kindly urge you to
>> improve/rewrite the slow and/or hacky python scripts we have in mesa.
>> This is a topic that was mentioned multiple times, and a part where
>> everyone will be glad to see some progress.
>>
>> Thanks
>> Emil
>
> The real goal here is to do mesa (in case I didn't make that clear either), 
> and
> the advantage for mesa is not just performance, it's that meson supports 
> visual
> studio on windows; which means that we could hopefully not just get faster
> builds, but also replace both autotools and scons with a single build system.
>
Yes that was more than clear. Yet it won't fly, I'm afraid.

The VMWare people like their SCons, and Meson is not a thing on
neither BSD(s), Solaris (and derivatives) nor Android :-\
If there's something "slow" say what/where and we can improve upon
things. You seems to be rewriting $world because someone sold you that
A is the holy grail.

I'll repeat my earlier request - your python skills/knowledge will be
greatly appreciated in existing parts of Mesa.
Speaking of which - you last work doesn't seem to have landed. What's
blocking it ?

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Hi Emil,

Quoting Emil Velikov (2017-03-16 16:35:33)
> While I can see you're impressed by Meson, I would kindly urge you to
> not use it here. As you look closely you can see that one could
> trivially improve the times, yet the biggest thing is that most of the
> code in libdrm must go ;-)

Perhaps I wasn't clear enough, I don't really expect this to land ever. I sent
it out more because I'd written it and it works and is a useful demonstration of
meson+ninja performance. Obviously 20 seconds -> 5 seconds isn't a huge deal :);
but in a larger project, consider that a 4x speedup would be 4 minutes to 1
minute, and that is a huge difference in time.

> 
> As the port is not 1:1 wrt the autoconf one, the performance numbers
> above are comparing apples to oranges.

I fail to see what I'm missing from meson that would have an effect on the
times I reported. There are some files that are installed by autoconf that I
didn't bother to install with meson (because I don't expect this to land). Since
I didn't time installs, I don't see how it isn't an apples to apples comparison.

I understand that libdrm is a pessimal case for recursive-make since most
sub folders contain < 5 C files, However, even if you were to flatten the make
files meson+ninja would still be faster when you consider that meson
configures and builds faster than autotools configures.

> If you/others are unhappy with the build times of libdrm - poke me on
> IRC. I will give you some easy tips on how to improve those.
> 
> You have some good python knowledge - I would kindly urge you to
> improve/rewrite the slow and/or hacky python scripts we have in mesa.
> This is a topic that was mentioned multiple times, and a part where
> everyone will be glad to see some progress.
> 
> Thanks
> Emil

The real goal here is to do mesa (in case I didn't make that clear either), and
the advantage for mesa is not just performance, it's that meson supports visual
studio on windows; which means that we could hopefully not just get faster
builds, but also replace both autotools and scons with a single build system.

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] [RFC libdrm 0/2] Replace the build system with meson

[Emil Velikov]

Hi Dylan,

On 16 March 2017 at 21:25, Dylan Baker  wrote:
> Why bother, and why would we want this?   
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson
>
While I can see you're impressed by Meson, I would kindly urge you to
not use it here. As you look closely you can see that one could
trivially improve the times, yet the biggest thing is that most of the
code in libdrm must go ;-)

As the port is not 1:1 wrt the autoconf one, the performance numbers
above are comparing apples to oranges.

If you/others are unhappy with the build times of libdrm - poke me on
IRC. I will give you some easy tips on how to improve those.

You have some good python knowledge - I would kindly urge you to
improve/rewrite the slow and/or hacky python scripts we have in mesa.
This is a topic that was mentioned multiple times, and a part where
everyone will be glad to see some progress.

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Marek Olšák (2017-03-16 15:36:26)
> Is there a way not to use ninja with meson, because ninja redirects
> all stderr output from gcc to stdout, which breaks many development
> environments that expect errors in stderr?
> 
> I'm basically saying that if ninja can't keep gcc errors in stderr, I
> wouldn't like any project that I might be involved in to require ninja
> for building.
> 
> Marek

There is no way to use another backend on Linux, and meson will not support
Make. Ninja is a big part of the appeal here, since it is faster than make is.
Are there particular tools you know don't work with ninja? It seems like in the
7+ years since ninja came out that someone would have fixed the tools, or that
some stream redirection could be used to fix the problem, "ninja 1>&2"?

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] [RFC libdrm 0/2] Replace the build system with meson

[Marek Olšák]

Is there a way not to use ninja with meson, because ninja redirects
all stderr output from gcc to stdout, which breaks many development
environments that expect errors in stderr?

I'm basically saying that if ninja can't keep gcc errors in stderr, I
wouldn't like any project that I might be involved in to require ninja
for building.

Marek

On Thu, Mar 16, 2017 at 10:25 PM, Dylan Baker  wrote:
> Why bother, and why would we want this?   
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)
>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson
>
> Dylan Baker (2):
>   Port build system to meson
>   remove autotools build
>
>  .editorconfig|   2 +-
>  .gitignore   |  82 +-
>  Makefile.am  | 144 +
>  Makefile.sources |  41 +--
>  README   |  21 +-
>  amdgpu/Makefile.am   |  47 +---
>  amdgpu/Makefile.sources  |  15 +-
>  amdgpu/libdrm_amdgpu.pc.in   |  11 +-
>  amdgpu/meson.build   |  57 +++-
>  autogen.sh   |  20 +-
>  configure.ac | 568 +
>  etnaviv/Makefile.am  |  26 +-
>  etnaviv/Makefile.sources |  12 +-
>  etnaviv/libdrm_etnaviv.pc.in |  11 +-
>  etnaviv/meson.build  |  56 +++-
>  exynos/Makefile.am   |  27 +--
>  exynos/libdrm_exynos.pc.in   |  11 +-
>  exynos/meson.build   |  52 +++-
>  freedreno/Makefile.am|  30 +--
>  freedreno/Makefile.sources   |  26 +-
>  freedreno/libdrm_freedreno.pc.in |  11 +-
>  freedreno/meson.build|  72 -
>  include/drm/meson.build  |  48 +++-
>  intel/Makefile.am|  73 +
>  intel/Makefile.sources   |  15 +-
>  intel/intel_bufmgr_gem.c |   8 +-
>  intel/libdrm_intel.pc.in |  11 +-
>  intel/meson.build|  55 +++-
>  libdrm.pc.in |  10 +-
>  libkms/Makefile.am   |  43 +--
>  libkms/Makefile.sources  |  23 +-
>  libkms/libkms.pc.in  |  11 +-
>  

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Ilia Mirkin (2017-03-16 14:32:09)
> On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
> > Why bother, and why would we want this? 
> >  │~
> >
> > First it's written in python, which means the potential developer base
> > is massive. And it provides a recursive view for humans, but a
> > non-recursive view for the system. This is the best of both worlds,
> > humans can organize the build system in a way that makes sense, and the
> > machine gets a non-recursive build system. It also uses ninja rather
> > than make, and ninja is faster than make inherently. Meson is also a
> > simpler syntax than autotools or cmake it's not Turing Complete by
> > design nor does it expose python, again, by design. This allows meson
> > itself to be reimplemented in a another language if python becomes a
> > dead-end or a bottle-neck. It also makes it much easier to understand
> > what the build system is doing.
> >
> > What's different about using meson?
> >
> > Well, apart from a faster builds and less magic in the build system? The
> > configure flags are different, it uses -D= more like cmake
> > than the --enable or --with flags of autotools, although oddly it uses
> > --prefix and friends when calling meson, but not with mesonconf, there's
> > a bug opened on this. Meson also doesn't support in-tree builds at all;
> > all builds are done out of tree. It also doesn't provide a "make dist"
> > target, fortunately there's this awesome tool called git, and it
> > provides a "git archive" command that does much the same thing. Did I
> > mention it's fast?
> >
> > Here are the performance numbers I see on a 2 core 4 thread SKL, without
> > initial configuration, and building out of tree (using zsh):
> >
> > For meson the command line is:
> > time (meson build -Dmanpages=true && ninja -C build)
> >
> > For autotools the command line is:
> > time (mdkir build && cd build && ../autotools && make -j5 -l4)
> 
> Probably mkdir...

derp, yeah.

> 
> >
> > meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> > autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> > meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> > autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
> >
> > That's ~4x faster for a cold build and ~10x faster for a hot build.
> >
> > For a make clean && make style build with a hot cache:
> > meson: 4.64s user 0.33s system 334% cpu 1.486 total
> > autotools: 7.93s user 0.32s system 167% cpu 4.920 total
> >
> > Why bother with libdrm?
> >
> > It's a simple build system, that could be completely (or mostly
> > completely) be ported in a very short time, and could serve as a tech
> > demo for the advantages of using meson to garner feedback for embarking
> > on a larger project, like mesa (which is what I'm planning to work on
> > next).
> >
> > tl;dr
> >
> > I wrote this as practice for porting Mesa, and figured I might as well
> > send it out since I wrote it.
> >
> > It is very likely that neither of these large patches will show up on the
> > mailing list, but this is available at my github:
> > https://github.com/dcbaker/libdrm wip/meson
> 
> I haven't looked at meson or your patches in detail, but autotools
> supports 2 very important use-cases very well:
> 
> 1. ./configure --help
> 2. Cross-compilation with minimal requirement from the project being built
> 
> Can you comment on how these are handled in meson?
> 
> Cheers,
> 
>   -ilia

1. mesonconf  provides much the same thing. You can also read the
meson_options.txt file, which is generally pretty short. I haven't added
descriptions to the options in this patch.

2. you write a small ini style configuration file, something like:
[binaries]
c = '/usr/bin/aarch64-linux-gnu-gc'
ar = '/usr/bin/aarch64-linux-gnu-gcc-ar'
strip = '/usr/bin/aarch64-linux-gnu-strip'
pkg-config = '/usr/bin/aarch64-linux-gnu-pkgconfig'

Then you just configure with:
meson build --cross-file cross_file.txt

then just ninja like normal

There's a more detailed walkthrough here:
https://github.com/mesonbuild/meson/wiki/Cross-compilation

I was able to cross compile the arm libraries for aarch64 using basically the
above configuration (I had to write a wrapper script for pkg-config to set a
couple of environment variables and install and archlinux aarach64 chroot,
because arch), of course, I don't have access to any arm machines that I could
test with.

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] [RFC libdrm 0/2] Replace the build system with meson

[Ilia Mirkin]

On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker  wrote:
> Why bother, and why would we want this?   
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)

Probably mkdir...

>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson

I haven't looked at meson or your patches in detail, but autotools
supports 2 very important use-cases very well:

1. ./configure --help
2. Cross-compilation with minimal requirement from the project being built

Can you comment on how these are handled in meson?

Cheers,

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

[Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Why bother, and why would we want this? 
 ???~

First it's written in python, which means the potential developer base
is massive. And it provides a recursive view for humans, but a
non-recursive view for the system. This is the best of both worlds,
humans can organize the build system in a way that makes sense, and the
machine gets a non-recursive build system. It also uses ninja rather
than make, and ninja is faster than make inherently. Meson is also a
simpler syntax than autotools or cmake it's not Turing Complete by
design nor does it expose python, again, by design. This allows meson
itself to be reimplemented in a another language if python becomes a
dead-end or a bottle-neck. It also makes it much easier to understand
what the build system is doing.

What's different about using meson?

Well, apart from a faster builds and less magic in the build system? The
configure flags are different, it uses -D= more like cmake
than the --enable or --with flags of autotools, although oddly it uses
--prefix and friends when calling meson, but not with mesonconf, there's
a bug opened on this. Meson also doesn't support in-tree builds at all;
all builds are done out of tree. It also doesn't provide a "make dist"
target, fortunately there's this awesome tool called git, and it
provides a "git archive" command that does much the same thing. Did I
mention it's fast?

Here are the performance numbers I see on a 2 core 4 thread SKL, without
initial configuration, and building out of tree (using zsh):

For meson the command line is:
time (meson build -Dmanpages=true && ninja -C build)

For autotools the command line is:
time (mdkir build && cd build && ../autotools && make -j5 -l4)

meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total

That's ~4x faster for a cold build and ~10x faster for a hot build.

For a make clean && make style build with a hot cache:
meson: 4.64s user 0.33s system 334% cpu 1.486 total
autotools: 7.93s user 0.32s system 167% cpu 4.920 total

Why bother with libdrm?

It's a simple build system, that could be completely (or mostly
completely) be ported in a very short time, and could serve as a tech
demo for the advantages of using meson to garner feedback for embarking
on a larger project, like mesa (which is what I'm planning to work on
next).

tl;dr

I wrote this as practice for porting Mesa, and figured I might as well
send it out since I wrote it.

It is very likely that neither of these large patches will show up on the
mailing list, but this is available at my github:
https://github.com/dcbaker/libdrm wip/meson

Dylan Baker (2):
  Port build system to meson
  remove autotools build

 .editorconfig|   2 +-
 .gitignore   |  82 +-
 Makefile.am  | 144 +
 Makefile.sources |  41 +--
 README   |  21 +-
 amdgpu/Makefile.am   |  47 +---
 amdgpu/Makefile.sources  |  15 +-
 amdgpu/libdrm_amdgpu.pc.in   |  11 +-
 amdgpu/meson.build   |  57 +++-
 autogen.sh   |  20 +-
 configure.ac | 568 +
 etnaviv/Makefile.am  |  26 +-
 etnaviv/Makefile.sources |  12 +-
 etnaviv/libdrm_etnaviv.pc.in |  11 +-
 etnaviv/meson.build  |  56 +++-
 exynos/Makefile.am   |  27 +--
 exynos/libdrm_exynos.pc.in   |  11 +-
 exynos/meson.build   |  52 +++-
 freedreno/Makefile.am|  30 +--
 freedreno/Makefile.sources   |  26 +-
 freedreno/libdrm_freedreno.pc.in |  11 +-
 freedreno/meson.build|  72 -
 include/drm/meson.build  |  48 +++-
 intel/Makefile.am|  73 +
 intel/Makefile.sources   |  15 +-
 intel/intel_bufmgr_gem.c |   8 +-
 intel/libdrm_intel.pc.in |  11 +-
 intel/meson.build|  55 +++-
 libdrm.pc.in |  10 +-
 libkms/Makefile.am   |  43 +--
 libkms/Makefile.sources  |  23 +-
 libkms/libkms.pc.in  |  11 +-
 libkms/meson.build   |  71 -
 m4/.gitignore|   5 +-
 man/Makefile.am  |  62 +---
 man/meson.build  | 119 +++-
 meson.build  | 288 -
 meson_config.h.in|  24 +-
 meson_options.txt|  16 +-
 nouveau/Makefile.am  |  33 +--
 nouveau/Makefile.sources |   9 +-
 nouveau/libdrm_nouveau.pc.in |  11 +-
 nouveau/meson.build  |  63 -
 omap/Makefile.am |  24 +-
 omap/libdrm_omap.pc.in   |  11 +-
 omap/meson.build