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:
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 proj
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*
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
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 de
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 inde
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 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 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 D
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 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 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
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
> >>> e
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
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:
>
>
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 seri
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 _c
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,
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
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.
> 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 annoy
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-g
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
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 M
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 o
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 (
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
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 que
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, whi
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
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),
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
> > > >
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
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
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 actuall
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 lo
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
> >
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
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 i
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 s
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
>> an
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 proj
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 bi
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
On 17/03/17 02:28, Brian Paul wrote:
On Thu, Mar 16, 2017 at 8:03 PM, Jason Ekstrand mailto:ja...@jlekstrand.net>> wrote:
On March 16, 2017 5:41:24 PM Emil Velikov mailto:emil.l.veli...@gmail.com>> wrote:
On 17 March 2017 at 00:21, Dylan Baker mailto:dy...@pnwbakers.com>> wrote:
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 basi
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
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 unm
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
>
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
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
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
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
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
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
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
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 onl
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
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
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.
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 matte
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?
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
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
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:
>> > > >
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
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
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 c
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 compatibili
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, pleas
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 afres
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.
>
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
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 ho
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
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
arbitr
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
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
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 mysel
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
> >> envi
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
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 ur
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 i
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 bas
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
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 ;-)
Perha
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
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,
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 involve
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 mas
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
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 bo
92 matches
Mail list logo
