Re: [Mesa-dev] Drop scons for 20.1?

2020-03-27 Thread Jose Fonseca



From: Michel Dänzer 
Sent: Friday, March 27, 2020 15:56
To: Jose Fonseca ; Marek Olšák 
Cc: Neha Bhende ; Kristian Høgsberg ; 
Dylan Baker ; mesa-dev 
Subject: Re: [Mesa-dev] Drop scons for 20.1?

On 2020-03-27 2:29 p.m., Jose Fonseca wrote:
>
> If SCons is such a time sink, then the best we can do is suggest to
> take it off Marge-bot.

That would be something like
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F4352data=02%7C01%7Cjfonseca%40vmware.com%7C786cd1eeae684a45dd3a08d7d26766aa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637209213877300351sdata=c9OoEsfgpIGhwoewerL%2Fb7ZShTr9CVCtLJdcMPLoUVk%3Dreserved=0
 then.

Not quite what I had in mind (I suggested take it off Marge-bot, as opposed to 
take it off completely.)  But lets continue the conversion in the MR.

For the record I also did make a 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4348 for reducing the 
targets as suggested by Marek, which I'd like to get in first.

> The onus of fixing SCons will go back to us, as it always did
> throughout these the past twelve years.

Not for the last year or so, when it's been part of the pre-merge CI
pipeline?
True.  And while I don't recall asking SCons to be added to pre-merge CI (I 
certainly did not), I do appreciate the effort and grief this might have 
caused.  Lets take it out.  As tiring fixing SCons by ourselves might be, is 
still better than being constantly painted as the bad guys and constantly have 
to fend off requests to yank off SCons.

Jose

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


Re: [Mesa-dev] Drop scons for 20.1?

2020-03-27 Thread Michel Dänzer
On 2020-03-27 2:29 p.m., Jose Fonseca wrote:
> 
> If SCons is such a time sink, then the best we can do is suggest to
> take it off Marge-bot.  

That would be something like
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4352 then.


> The onus of fixing SCons will go back to us, as it always did
> throughout these the past twelve years.

Not for the last year or so, when it's been part of the pre-merge CI
pipeline?


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Drop scons for 20.1?

2020-03-27 Thread Jose Fonseca
In the long term we should reduce the complexity of the project. scons is a 
maintenance burden.
We all agree here.  And we are making progress.  Even a couple of weeks ago I 
had to debug and fix weird Meson behaviour -- 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4186
 Every time I break the scons build and the CI reports it, can I politely ask 
you to fix my MR instead of me doing it? Then at least the real maintenance 
cost would be known to scons supporters, instead of the cost being invisible to 
most.
Sure.  But first I want all the time back I spent fixing scons and msvc builds 
when the cost was invisible to most.  Even after setting up Appveyor people 
ignored the successive build failures.  Even when fix was plain trivial and 
easily avoidable (like replacing non-standard `= {}`  initializers for `= { 0 
}`).   Even when I politely asked to fix it, people ignored.  Not you perhaps, 
but several did.

Honestly, why do you blame me/us?  Mesa had multiple build systems for all its 
life -- all with different state of brokenness.   What really changed these 
days is not actually the Meson-holy-grail, but this new Marge-bot overlord.  
Personally I find it this new process a tad too draconian.

If SCons is such a time sink, then the best we can do is suggest to take it off 
Marge-bot.  The onus of fixing SCons will go back to us, as it always did 
throughout these the past twelve years.

BTW, the grief you and others might be experiencing now, is probably 1/100th of 
what we systematically had throughout these years.  I particularly recall all 
the pain and grief to replicate all the autoconf build logic for code 
generation every time there was a major addition / refactoring in Mesa -- in 
particular all those Python scripts that generated C code are very difficult to 
match, because unlike Autoconf, SCons had fined grained dependencies, so 
missing one dependency meant incremental builds would use stale source code.  
Some times there were more broken builds that good ones.  Even git-bisecting 
was extremely had as result.  Though to be fair, I do recall I also moaned and 
bitch about it too.
In the mean time, I think we can remove all parts of scons that VMWare does NOT 
care about. Do you need haiku-softpipe? Do you need graw-null? Do you need swr? 
glx? There is bunch you don't really need on Windows.
Now that is a more serious proposal.  An excellent one in fact.

The only scons targets we need are libgl-gdi (and its dependencies, including 
llvmpipe) and svga.

Everything else can go as far as we are concerned.  graw was useful at one 
point, but I don't think it's that useful anymore.  Regarding haiku-softpipe 
and swr targets, they were not added to SCons by VMware.  I suppose if the 
stakeholders didn't speak up so far, one can assume they don't care.

Jose


From: Marek Olšák 
Sent: Friday, March 27, 2020 00:56
To: Jose Fonseca 
Cc: Jason Ekstrand ; Rob Clark ; 
Kristian Høgsberg ; mesa-dev 
; Dylan Baker 
Subject: Re: [Mesa-dev] Drop scons for 20.1?

In the long term we should reduce the complexity of the project. scons is a 
maintenance burden. Every time I break the scons build and the CI reports it, 
can I politely ask you to fix my MR instead of me doing it? Then at least the 
real maintenance cost would be known to scons supporters, instead of the cost 
being invisible to most.

In the mean time, I think we can remove all parts of scons that VMWare does NOT 
care about. Do you need haiku-softpipe? Do you need graw-null? Do you need swr? 
glx? There is bunch you don't really need on Windows.

Marek

On Wed, Feb 26, 2020 at 3:44 PM Jose Fonseca 
mailto:jfons...@vmware.com>> wrote:
We already solved some pieces (e.g, how to consume and use Meson, while 
following our internal legal process required for adding new 3rd party 
dependencies), and figured a way to consume Meson build without having to 
migrate lots of internal build logic from Scons to Meson.  But other stuff just 
keeps getting higher priority, and we haven't fully migrated.

Please do understand, SCons just works for us.  We are making progress with 
Meson.  It's just not the highest priority, when time is short, it gets 
deferred.

I don't understand the rush.  If it was trivial and easy we'd obviously would 
have done it.

Jose


From: Jason Ekstrand mailto:ja...@jlekstrand.net>>
Sent: Wednesday, February 26, 2020 04:15
To: Rob Clark mailto:robdcl...@gmail.com>>; Kristian 
Høgsberg mailto:hoegsb...@gmail.com>>
Cc: mesa-dev 
mailto:mesa-dev@lists.freedesktop.org>>; Dylan 
Baker mailto:baker.dyla...@gmail.com>>; Jose Fonseca 
mailto:jfons...@vmware.com>>; Brian Paul 
mailto:bri...@vmware.com>>
Subject: Re: [Mesa-dev] Drop scons for 20.1?

+Jose & Brian

I'm not personally opposed but I also can't remember the last time I had to
fix the scons build. I think it's been years. Maybe that's beca

Re: [Mesa-dev] Drop scons for 20.1?

2020-03-26 Thread Marek Olšák
In the long term we should reduce the complexity of the project. scons is a
maintenance burden. Every time I break the scons build and the CI reports
it, can I politely ask you to fix my MR instead of me doing it? Then at
least the real maintenance cost would be known to scons supporters, instead
of the cost being invisible to most.

In the mean time, I think we can remove all parts of scons that VMWare does
NOT care about. Do you need haiku-softpipe? Do you need graw-null? Do you
need swr? glx? There is bunch you don't really need on Windows.

Marek

On Wed, Feb 26, 2020 at 3:44 PM Jose Fonseca  wrote:

> We already solved some pieces (e.g, how to consume and use Meson, while
> following our internal legal process required for adding new 3rd party
> dependencies), and figured a way to consume Meson build without having to
> migrate lots of internal build logic from Scons to Meson.  But other stuff
> just keeps getting higher priority, and we haven't fully migrated.
>
> Please do understand, SCons *just* *works* for us.  We are making
> progress with Meson.  It's just not the highest priority, when time is
> short, it gets deferred.
>
> I don't understand the rush.  If it was trivial and easy we'd obviously
> would have done it.
>
> Jose
>
> --
> *From:* Jason Ekstrand 
> *Sent:* Wednesday, February 26, 2020 04:15
> *To:* Rob Clark ; Kristian Høgsberg <
> hoegsb...@gmail.com>
> *Cc:* mesa-dev ; Dylan Baker <
> baker.dyla...@gmail.com>; Jose Fonseca ; Brian Paul <
> bri...@vmware.com>
> *Subject:* Re: [Mesa-dev] Drop scons for 20.1?
>
> +Jose & Brian
>
> I'm not personally opposed but I also can't remember the last time I had
> to
> fix the scons build. I think it's been years. Maybe that's because I don't
> work on GL anymore? In any case, I don't know that it's really costing us
> that much given that basically none of the drivers actually build with it.
> But fat meh, I guess.
>
> --Jason
>
> On February 25, 2020 21:56:30 Rob Clark  wrote:
>
> > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > that costs us, but I guess those cycles could be put to better use?
> > So even ignoring the developer-cycles issue (ie. someone making
> > changes that effects scons build, and has to setup a scons build env
> > to fix breakage of their MR) I guess there is at least an argument to
> > remove scons from CI.  Whether it is worth keeping a dead build system
> > after it is removed from CI is an issue that I'm ambivalent about.
> >
> > BR,
> > -R
> >
> > On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg 
> wrote:
> >>
> >> It's been a while since Dylan did the work to make meson support
> >> Windows and there's been plenty of time to provide feedback or improve
> >> argue why we still need scons. I haven't seen any such discussion and
> >> I think we've waited long enough.
> >>
> >> Let's drop scons for the next release and move things forward?
> >>
> >> Kristian
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7Cc8b86d6f312c48d77f3c08d7ba72774f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637182873108493719sdata=oKvqrkRoo6%2FqGW5BWbe1exIcBF%2BI%2BblcWIIVo3iW9J0%3Dreserved=0
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7Cc8b86d6f312c48d77f3c08d7ba72774f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637182873108493719sdata=oKvqrkRoo6%2FqGW5BWbe1exIcBF%2BI%2BblcWIIVo3iW9J0%3Dreserved=0
>
>
>
> ___
> 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] Drop scons for 20.1?

2020-03-24 Thread Daniel Stone
Hi,

On Tue, 25 Feb 2020 at 23:42, Kristian Høgsberg  wrote:
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited long enough.

Dylan's work didn't get enabled by default, and also depended on
Windows runners having a system environment set up. Taking a little
bit of work from the GStreamer side, I wrote a native Windows VS2019
CI which also uses Docker to build in:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4304

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


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Brian Paul
I'm on vacation this week. When I get back next week we'll talk about this
again at VMware. Unfortunately, integrating a new build tool into our
infrastructure here can be pretty difficult.  But I totally understand the
appeal of getting rid of SCons.  Please hold on a bit...

-Brian



On Wed, Feb 26, 2020 at 2:04 PM Kristian Høgsberg 
wrote:

> On Wed, Feb 26, 2020 at 12:16 PM Jose Fonseca  wrote:
> >
> > > but it bothers me how we keep not making a decision on this. If we'd
> said, "let's keep it and support it", that would something.
> >
> > I'm surprised there's any doubt.
> >
> > SCons works great for us.   Meson gives no immediate benefit for us
> other than headaches.  If we cared about nothing but ourselves, we'd keep
> SCons indefinitely, until it became a pain.
> >
> > The only reason we don't stubbornly put the foot down is that we
> understand that having one single build system would be beneficial the
> whole community, and of course we appreciate all the work Dylan and others
> did to get Meson to work on Windows, so we'd like to get there one day.
> >
> > That said, I don't understand why the rest of the Mesa community putting
> a gun against our head to abandon SCons.
> >
> > Aren't we maintaining the SCons build?  Since when in Mesa community are
> some entitled to start remove code that still works, is used, and
> maintained by others
>
> Nobody is entitled to remove the code, that's why we're having this
> discussion. And I bet it's frustrating for you to have to deal with
> this again and again, but on the other side, it's frustrating to see
> this issue come up again and again with no evident progress
> whatsoever. What has happened on your side since the last time this
> was discussed? When is that "one day"? How are we supposed to move
> this forward without bringing it up?
>
> As for removing code that works - we do that All. The. Time. We
> refactor subsystems, IRs, entire drivers get rewritten and replace the
> working code that was there before, in order the lower the maintenance
> burden, run across more platforms, shader a compiler pass, reduce
> techincal debt etc.
>
> Kristian
>
> >
> > Jose
> >
> > 
> > From: Kristian Høgsberg 
> > Sent: Wednesday, February 26, 2020 18:37
> > To: Jason Ekstrand 
> > Cc: Rob Clark ; mesa-dev <
> mesa-dev@lists.freedesktop.org>; Dylan Baker ;
> Jose Fonseca ; Brian Paul 
> > Subject: Re: [Mesa-dev] Drop scons for 20.1?
> >
> > On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand 
> wrote:
> > >
> > > +Jose & Brian
> > >
> > > I'm not personally opposed but I also can't remember the last time I
> had to
> > > fix the scons build. I think it's been years. Maybe that's because I
> don't
> > > work on GL anymore? In any case, I don't know that it's really costing
> us
> > > that much given that basically none of the drivers actually build with
> it.
> > > But fat meh, I guess.
> >
> > Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
> > that I thought it would be:
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F3955data=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=96lM4flW9ja6fJG95nlNdmftNiYpajxpg0Il850%2FDLk%3Dreserved=0
> >
> > but it bothers me how we keep not making a decision on this. If we'd
> > said, "let's keep it and support it", that would something. But
> > whenever it comes up, Dylan maybe fixes something on the windows
> > build, we talk about trying to switch Windows to meson and then...
> > nothing.
> >
> > Also, we've had this unfortunate split between Linux and Windows build
> > systems where autotools suck on Windows and nobody on Unix ever had a
> > reason to use SCons.  With meson we've picked something that's a
> > legitimate improvement on both sides, get's us back to one build
> > system and done more than due dilligence to make it work on Windows
> > and we're not taking the last step because... meh?
> >
> > Kristian
> >
> > > --Jason
> > >
> > > On February 25, 2020 21:56:30 Rob Clark  wrote:
> > >
> > > > It looks like we have 4 scons build jobs in CI.. I'm not sure how
> much
> > > > that costs us, but I guess those cycles could be put to better use?
> > > > So even ignoring the developer-cycles issue (ie. someone making
> > &g

Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Kristian Høgsberg
On Wed, Feb 26, 2020 at 12:16 PM Jose Fonseca  wrote:
>
> > but it bothers me how we keep not making a decision on this. If we'd said, 
> > "let's keep it and support it", that would something.
>
> I'm surprised there's any doubt.
>
> SCons works great for us.   Meson gives no immediate benefit for us other 
> than headaches.  If we cared about nothing but ourselves, we'd keep SCons 
> indefinitely, until it became a pain.
>
> The only reason we don't stubbornly put the foot down is that we understand 
> that having one single build system would be beneficial the whole community, 
> and of course we appreciate all the work Dylan and others did to get Meson to 
> work on Windows, so we'd like to get there one day.
>
> That said, I don't understand why the rest of the Mesa community putting a 
> gun against our head to abandon SCons.
>
> Aren't we maintaining the SCons build?  Since when in Mesa community are some 
> entitled to start remove code that still works, is used, and maintained by 
> others

Nobody is entitled to remove the code, that's why we're having this
discussion. And I bet it's frustrating for you to have to deal with
this again and again, but on the other side, it's frustrating to see
this issue come up again and again with no evident progress
whatsoever. What has happened on your side since the last time this
was discussed? When is that "one day"? How are we supposed to move
this forward without bringing it up?

As for removing code that works - we do that All. The. Time. We
refactor subsystems, IRs, entire drivers get rewritten and replace the
working code that was there before, in order the lower the maintenance
burden, run across more platforms, shader a compiler pass, reduce
techincal debt etc.

Kristian

>
> Jose
>
> 
> From: Kristian Høgsberg 
> Sent: Wednesday, February 26, 2020 18:37
> To: Jason Ekstrand 
> Cc: Rob Clark ; mesa-dev 
> ; Dylan Baker ; Jose 
> Fonseca ; Brian Paul 
> Subject: Re: [Mesa-dev] Drop scons for 20.1?
>
> On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand  wrote:
> >
> > +Jose & Brian
> >
> > I'm not personally opposed but I also can't remember the last time I had to
> > fix the scons build. I think it's been years. Maybe that's because I don't
> > work on GL anymore? In any case, I don't know that it's really costing us
> > that much given that basically none of the drivers actually build with it.
> > But fat meh, I guess.
>
> Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
> that I thought it would be:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F3955data=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=96lM4flW9ja6fJG95nlNdmftNiYpajxpg0Il850%2FDLk%3Dreserved=0
>
> but it bothers me how we keep not making a decision on this. If we'd
> said, "let's keep it and support it", that would something. But
> whenever it comes up, Dylan maybe fixes something on the windows
> build, we talk about trying to switch Windows to meson and then...
> nothing.
>
> Also, we've had this unfortunate split between Linux and Windows build
> systems where autotools suck on Windows and nobody on Unix ever had a
> reason to use SCons.  With meson we've picked something that's a
> legitimate improvement on both sides, get's us back to one build
> system and done more than due dilligence to make it work on Windows
> and we're not taking the last step because... meh?
>
> Kristian
>
> > --Jason
> >
> > On February 25, 2020 21:56:30 Rob Clark  wrote:
> >
> > > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > > that costs us, but I guess those cycles could be put to better use?
> > > So even ignoring the developer-cycles issue (ie. someone making
> > > changes that effects scons build, and has to setup a scons build env
> > > to fix breakage of their MR) I guess there is at least an argument to
> > > remove scons from CI.  Whether it is worth keeping a dead build system
> > > after it is removed from CI is an issue that I'm ambivalent about.
> > >
> > > BR,
> > > -R
> > >
> > > On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  
> > > wrote:
> > >>
> > >> It's been a while since Dylan did the work to make meson support
> > >> Windows and there's been plenty of time to provide feedback or improve
> > >> argue why we still need scons. I haven't seen any such discussion and
> > >>

Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Jose Fonseca
We already solved some pieces (e.g, how to consume and use Meson, while 
following our internal legal process required for adding new 3rd party 
dependencies), and figured a way to consume Meson build without having to 
migrate lots of internal build logic from Scons to Meson.  But other stuff just 
keeps getting higher priority, and we haven't fully migrated.

Please do understand, SCons just works for us.  We are making progress with 
Meson.  It's just not the highest priority, when time is short, it gets 
deferred.

I don't understand the rush.  If it was trivial and easy we'd obviously would 
have done it.

Jose


From: Jason Ekstrand 
Sent: Wednesday, February 26, 2020 04:15
To: Rob Clark ; Kristian Høgsberg 
Cc: mesa-dev ; Dylan Baker 
; Jose Fonseca ; Brian Paul 

Subject: Re: [Mesa-dev] Drop scons for 20.1?

+Jose & Brian

I'm not personally opposed but I also can't remember the last time I had to
fix the scons build. I think it's been years. Maybe that's because I don't
work on GL anymore? In any case, I don't know that it's really costing us
that much given that basically none of the drivers actually build with it.
But fat meh, I guess.

--Jason

On February 25, 2020 21:56:30 Rob Clark  wrote:

> It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> that costs us, but I guess those cycles could be put to better use?
> So even ignoring the developer-cycles issue (ie. someone making
> changes that effects scons build, and has to setup a scons build env
> to fix breakage of their MR) I guess there is at least an argument to
> remove scons from CI.  Whether it is worth keeping a dead build system
> after it is removed from CI is an issue that I'm ambivalent about.
>
> BR,
> -R
>
> On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  wrote:
>>
>> It's been a while since Dylan did the work to make meson support
>> Windows and there's been plenty of time to provide feedback or improve
>> argue why we still need scons. I haven't seen any such discussion and
>> I think we've waited long enough.
>>
>> Let's drop scons for the next release and move things forward?
>>
>> Kristian
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7Cc8b86d6f312c48d77f3c08d7ba72774f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637182873108493719sdata=oKvqrkRoo6%2FqGW5BWbe1exIcBF%2BI%2BblcWIIVo3iW9J0%3Dreserved=0
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7Cc8b86d6f312c48d77f3c08d7ba72774f%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637182873108493719sdata=oKvqrkRoo6%2FqGW5BWbe1exIcBF%2BI%2BblcWIIVo3iW9J0%3Dreserved=0



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


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Rob Clark
On Wed, Feb 26, 2020 at 12:16 PM Jose Fonseca  wrote:
>
> > but it bothers me how we keep not making a decision on this. If we'd said, 
> > "let's keep it and support it", that would something.
>
> I'm surprised there's any doubt.
>
> SCons works great for us.   Meson gives no immediate benefit for us other 
> than headaches.  If we cared about nothing but ourselves, we'd keep SCons 
> indefinitely, until it became a pain.
>
> The only reason we don't stubbornly put the foot down is that we understand 
> that having one single build system would be beneficial the whole community, 
> and of course we appreciate all the work Dylan and others did to get Meson to 
> work on Windows, so we'd like to get there one day.
>
> That said, I don't understand why the rest of the Mesa community putting a 
> gun against our head to abandon SCons.
>
> Aren't we maintaining the SCons build?  Since when in Mesa community are some 
> entitled to start remove code that still works, is used, and maintained by 
> others
>

currently scons build is in CI, so for anyone making build system
changes that effects code that is part of the scons build, they have
to go and read enough stack-overflow to figure out how to make the
same changes in scons ;-)


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


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Jose Fonseca
> but it bothers me how we keep not making a decision on this. If we'd said, 
> "let's keep it and support it", that would something.

I'm surprised there's any doubt.

SCons works great for us.   Meson gives no immediate benefit for us other than 
headaches.  If we cared about nothing but ourselves, we'd keep SCons 
indefinitely, until it became a pain.

The only reason we don't stubbornly put the foot down is that we understand 
that having one single build system would be beneficial the whole community, 
and of course we appreciate all the work Dylan and others did to get Meson to 
work on Windows, so we'd like to get there one day.

That said, I don't understand why the rest of the Mesa community putting a gun 
against our head to abandon SCons.

Aren't we maintaining the SCons build?  Since when in Mesa community are some 
entitled to start remove code that still works, is used, and maintained by 
others

Jose


From: Kristian Høgsberg 
Sent: Wednesday, February 26, 2020 18:37
To: Jason Ekstrand 
Cc: Rob Clark ; mesa-dev ; 
Dylan Baker ; Jose Fonseca ; 
Brian Paul 
Subject: Re: [Mesa-dev] Drop scons for 20.1?

On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand  wrote:
>
> +Jose & Brian
>
> I'm not personally opposed but I also can't remember the last time I had to
> fix the scons build. I think it's been years. Maybe that's because I don't
> work on GL anymore? In any case, I don't know that it's really costing us
> that much given that basically none of the drivers actually build with it.
> But fat meh, I guess.

Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
that I thought it would be:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fmesa%2Fmesa%2F-%2Fmerge_requests%2F3955data=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=96lM4flW9ja6fJG95nlNdmftNiYpajxpg0Il850%2FDLk%3Dreserved=0

but it bothers me how we keep not making a decision on this. If we'd
said, "let's keep it and support it", that would something. But
whenever it comes up, Dylan maybe fixes something on the windows
build, we talk about trying to switch Windows to meson and then...
nothing.

Also, we've had this unfortunate split between Linux and Windows build
systems where autotools suck on Windows and nobody on Unix ever had a
reason to use SCons.  With meson we've picked something that's a
legitimate improvement on both sides, get's us back to one build
system and done more than due dilligence to make it work on Windows
and we're not taking the last step because... meh?

Kristian

> --Jason
>
> On February 25, 2020 21:56:30 Rob Clark  wrote:
>
> > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > that costs us, but I guess those cycles could be put to better use?
> > So even ignoring the developer-cycles issue (ie. someone making
> > changes that effects scons build, and has to setup a scons build env
> > to fix breakage of their MR) I guess there is at least an argument to
> > remove scons from CI.  Whether it is worth keeping a dead build system
> > after it is removed from CI is an issue that I'm ambivalent about.
> >
> > BR,
> > -R
> >
> > On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  
> > wrote:
> >>
> >> It's been a while since Dylan did the work to make meson support
> >> Windows and there's been plenty of time to provide feedback or improve
> >> argue why we still need scons. I haven't seen any such discussion and
> >> I think we've waited long enough.
> >>
> >> Let's drop scons for the next release and move things forward?
> >>
> >> Kristian
> >> ___
> >> mesa-dev mailing list
> >> mesa-dev@lists.freedesktop.org
> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=d40ceGVLhyahNydLEZ55P7hgjqeLtIOMKN6J0NPmfwE%3Dreserved=0
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cjfonseca%40vmware.com%7C6b2e8f2abc98458d18ad08d7baeb0443%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637183390863817583sdata=d40ceGVLhyahNydLEZ55P7hgjqeLtIOMKN6J0NPmfwE%3Dreserved=0
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Kristian Høgsberg
On Tue, Feb 25, 2020 at 8:15 PM Jason Ekstrand  wrote:
>
> +Jose & Brian
>
> I'm not personally opposed but I also can't remember the last time I had to
> fix the scons build. I think it's been years. Maybe that's because I don't
> work on GL anymore? In any case, I don't know that it's really costing us
> that much given that basically none of the drivers actually build with it.
> But fat meh, I guess.

Maybe it is a bit meh... I did the MR to remove SCons and it's smaller
that I thought it would be:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3955

but it bothers me how we keep not making a decision on this. If we'd
said, "let's keep it and support it", that would something. But
whenever it comes up, Dylan maybe fixes something on the windows
build, we talk about trying to switch Windows to meson and then...
nothing.

Also, we've had this unfortunate split between Linux and Windows build
systems where autotools suck on Windows and nobody on Unix ever had a
reason to use SCons.  With meson we've picked something that's a
legitimate improvement on both sides, get's us back to one build
system and done more than due dilligence to make it work on Windows
and we're not taking the last step because... meh?

Kristian

> --Jason
>
> On February 25, 2020 21:56:30 Rob Clark  wrote:
>
> > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > that costs us, but I guess those cycles could be put to better use?
> > So even ignoring the developer-cycles issue (ie. someone making
> > changes that effects scons build, and has to setup a scons build env
> > to fix breakage of their MR) I guess there is at least an argument to
> > remove scons from CI.  Whether it is worth keeping a dead build system
> > after it is removed from CI is an issue that I'm ambivalent about.
> >
> > BR,
> > -R
> >
> > On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  
> > wrote:
> >>
> >> It's been a while since Dylan did the work to make meson support
> >> Windows and there's been plenty of time to provide feedback or improve
> >> argue why we still need scons. I haven't seen any such discussion and
> >> I think we've waited long enough.
> >>
> >> Let's drop scons for the next release and move things forward?
> >>
> >> Kristian
> >> ___
> >> 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
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Eric Anholt
On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  wrote:
>
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited long enough.
>
> Let's drop scons for the next release and move things forward?

I agree.  We shouldn't be spending project resources (developer time,
CI machine time) on a duplicate build system for a closed source fork
of Mesa.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Rob Clark
On Wed, Feb 26, 2020 at 2:07 AM Michel Dänzer  wrote:
>
> On 2020-02-26 4:56 a.m., Rob Clark wrote:
> > It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> > that costs us, but I guess those cycles could be put to better use?
> > So even ignoring the developer-cycles issue (ie. someone making
> > changes that effects scons build, and has to setup a scons build env
> > to fix breakage of their MR) I guess there is at least an argument to
> > remove scons from CI.  Whether it is worth keeping a dead build system
> > after it is removed from CI is an issue that I'm ambivalent about.
>
> As long as it's supported, it needs to be tested in CI.
>

Well, I mean, removed from CI (but files left in place) would put it
at the same level of "support" as android build.  Ie. not tested in CI
and doesn't block merging changes, but people who use it are on the
hook for pushing fixes when it does break.


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


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread apinheiro

On 26/2/20 5:15, Jason Ekstrand wrote:
> +Jose & Brian
>
> I'm not personally opposed but I also can't remember the last time I
> had to fix the scons build. I think it's been years. Maybe that's
> because I don't work on GL anymore? 


I bet that the latter. I remember some years ago pushing new code (I
think that was the initial ARB_gl_spirv code), updating the meson and
autotools files (we were still on transition), and found when the code
was I pushed broke the scons build. Moving from three build systems to
two was good. If possible I really think that it would be a good idea to
move from two to one.


> In any case, I don't know that it's really costing us that much given
> that basically none of the drivers actually build with it. But fat
> meh, I guess.
>
> --Jason
>
> On February 25, 2020 21:56:30 Rob Clark  wrote:
>
>> It looks like we have 4 scons build jobs in CI.. I'm not sure how much
>> that costs us, but I guess those cycles could be put to better use?
>> So even ignoring the developer-cycles issue (ie. someone making
>> changes that effects scons build, and has to setup a scons build env
>> to fix breakage of their MR) I guess there is at least an argument to
>> remove scons from CI.  Whether it is worth keeping a dead build system
>> after it is removed from CI is an issue that I'm ambivalent about.
>>
>> BR,
>> -R
>>
>> On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg
>>  wrote:
>>>
>>> It's been a while since Dylan did the work to make meson support
>>> Windows and there's been plenty of time to provide feedback or improve
>>> argue why we still need scons. I haven't seen any such discussion and
>>> I think we've waited long enough.
>>>
>>> Let's drop scons for the next release and move things forward?
>>>
>>> Kristian
>>> ___
>>> 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
>
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


pEpkey.asc
Description: application/pgp-keys
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-26 Thread Michel Dänzer
On 2020-02-26 4:56 a.m., Rob Clark wrote:
> It looks like we have 4 scons build jobs in CI.. I'm not sure how much
> that costs us, but I guess those cycles could be put to better use?
> So even ignoring the developer-cycles issue (ie. someone making
> changes that effects scons build, and has to setup a scons build env
> to fix breakage of their MR) I guess there is at least an argument to
> remove scons from CI.  Whether it is worth keeping a dead build system
> after it is removed from CI is an issue that I'm ambivalent about.

As long as it's supported, it needs to be tested in CI.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-25 Thread Jason Ekstrand

+Jose & Brian

I'm not personally opposed but I also can't remember the last time I had to 
fix the scons build. I think it's been years. Maybe that's because I don't 
work on GL anymore? In any case, I don't know that it's really costing us 
that much given that basically none of the drivers actually build with it. 
But fat meh, I guess.


--Jason

On February 25, 2020 21:56:30 Rob Clark  wrote:


It looks like we have 4 scons build jobs in CI.. I'm not sure how much
that costs us, but I guess those cycles could be put to better use?
So even ignoring the developer-cycles issue (ie. someone making
changes that effects scons build, and has to setup a scons build env
to fix breakage of their MR) I guess there is at least an argument to
remove scons from CI.  Whether it is worth keeping a dead build system
after it is removed from CI is an issue that I'm ambivalent about.

BR,
-R

On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  wrote:


It's been a while since Dylan did the work to make meson support
Windows and there's been plenty of time to provide feedback or improve
argue why we still need scons. I haven't seen any such discussion and
I think we've waited long enough.

Let's drop scons for the next release and move things forward?

Kristian
___
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




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


Re: [Mesa-dev] Drop scons for 20.1?

2020-02-25 Thread Rob Clark
It looks like we have 4 scons build jobs in CI.. I'm not sure how much
that costs us, but I guess those cycles could be put to better use?
So even ignoring the developer-cycles issue (ie. someone making
changes that effects scons build, and has to setup a scons build env
to fix breakage of their MR) I guess there is at least an argument to
remove scons from CI.  Whether it is worth keeping a dead build system
after it is removed from CI is an issue that I'm ambivalent about.

BR,
-R

On Tue, Feb 25, 2020 at 3:42 PM Kristian Høgsberg  wrote:
>
> It's been a while since Dylan did the work to make meson support
> Windows and there's been plenty of time to provide feedback or improve
> argue why we still need scons. I haven't seen any such discussion and
> I think we've waited long enough.
>
> Let's drop scons for the next release and move things forward?
>
> Kristian
> ___
> 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