Re: [Mesa-dev] Lets talk about autotools

[Stuart Young]

Hi Dylan,

The architecture name in Debian is definitely ppc64el (not ppc64le).
However, it's the IBM Power platform (POWER8) running in little endian mode
(which yes, is confusing).

 https://wiki.debian.org/ppc64el
 https://wiki.debian.org/ArchiveQualification/ppc64el

FWIW: Apparently there's free access to full VM's at
http://openpower.ic.unicamp.br/minicloud/ for developers, which might prove
useful if the build parts turn hairy.

Note: Haven't requested one myself.. tho I was looking into doing so a few
months ago).


On Tue, 4 Dec 2018 at 07:11, Dylan Baker  wrote:

> Quoting Timo Aaltonen (2018-12-03 11:03:59)
> > On 3.12.2018 20.54, Dylan Baker wrote:
> > > Quoting Timo Aaltonen (2018-12-03 10:36:12)
> > >> On 3.12.2018 20.25, Emil Velikov wrote:
> > >>> On Mon, 3 Dec 2018 at 17:49, Dylan Baker 
> wrote:
> > 
> >  Quoting Emil Velikov (2018-12-03 07:54:38)
> > > Hi all,
> > >
> > > On Thu, 29 Nov 2018 at 17:44, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> I can see why people may opt to not use or maintain the autotools
> build.
> > >> Although I would kindly ask that we do not remove it just yet.
> > >>
> > >> In Mesa, we have different parts not used by different teams. As
> such
> > >> we tend to remove stuff when nobody is around to maintain it
> anymore.
> > >>
> > >> That said, I'm planning to continue maintaining it and would
> appreciate
> > >> if we keep it in-tree.
> > >>
> > >> As people may be concerned about bugreports and alike we can
> trivially
> > >> add a warning (as configure is invoked) to forwards any issues to
> my
> > >> email. Additionally (or alternatively) we can have an autotools
> bugzilla
> > >> category with me as the default assignee.
> > >>
> > >
> > > Seems like I failed to make things clear enough with earlier
> message.
> > >
> > > There is _no_ expectation for anyone to touch or even look at
> autotools.
> > > Hence, my suggestion to have configure.ac point people to me in
> case of issues.
> > >
> > > If people have CI that uses it - feel free to drop it.
> > >
> > 
> >  I've tried to stay out of this discussion, because everyone knows
> my opinion,
> >  and I feel I don't have much to add, however...
> > 
> > >
> > > That said, many have asked why I'd go through the pain of
> maintaining it:
> > >  - Most Linux distributions have switched, but there'still a few
> outstanding
> > >  - Non Linux distributions have not switched
> > 
> >  Haiku has at least :)
> > 
> > >>> \o/
> > >>
> > >> And Debian too (in experimental). Ubuntu will follow once the final is
> > >> out and it build everywhere. There's a build failure on ppc64el, btw:
> > >>
> > >>
> https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0
> > >>
> > >  - The meson build is missing features, relative the autotools one
> > 
> >  The only feature that I know that meson does not have relative to
> autotools is
> >  the gl mangling stuff (which is intentional, we'll add it if
> someone shows up
> >  with a need for it). Everything else is either intentionally not
> implemented
> >  (GLX TLS toggling for example, which meson hardcodes on for OSes
> that support
> >  it, and off for those that don't).
> > 
> > >>> On top of the TLS and symbol mangling (for which I agree) there is:
> > >>>  - disable direct glx - non linux people use this
> > >>
> > >> This seems to work, at least on Hurd:
> > >>
> > >> diff --git a/meson.build b/meson.build
> > >> index 33f4e5ad3cf..90cc0bb3af2 100644
> > >> --- a/meson.build
> > >> +++ b/meson.build
> > >> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
> > >>  with_valgrind = get_option('valgrind')
> > >>  with_libunwind = get_option('libunwind')
> > >>  with_asm = get_option('asm')
> > >> +with_glx_direct= get_option('glx-direct')
>
> There should be a space between t and =
>
> > >>  with_glx_read_only_text = get_option('glx-read-only-text')
> > >>  with_osmesa = get_option('osmesa')
> > >>  with_swr_arches = get_option('swr-arches')
> > >> @@ -370,9 +371,6 @@ if with_glvnd
> > >>endif
> > >>  endif
> > >>
> > >> -# TODO: toggle for this
> > >> -with_glx_direct = true
> > >> -
> > >>  if with_vulkan_icd_dir == ''
> > >>with_vulkan_icd_dir = join_paths(get_option('datadir'),
> 'vulkan/icd.d')
> > >>  endif
> > >> diff --git a/meson_options.txt b/meson_options.txt
> > >> index a1d5ab0e185..4d5f36bf33d 100644
> > >> --- a/meson_options.txt
> > >> +++ b/meson_options.txt
> > >> @@ -205,6 +205,12 @@ option(
> > >>choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
> > >>description : 'Build support for GLX platform'
> > >>  )
> > >> +option(
> > >> +  'glx-direct',
> > >> +  type : 'boolean',
> > >> +  value : 'true',
> > >> +  description : 'Enable direct rendering in 

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Timo Aaltonen (2018-12-03 11:03:59)
> On 3.12.2018 20.54, Dylan Baker wrote:
> > Quoting Timo Aaltonen (2018-12-03 10:36:12)
> >> On 3.12.2018 20.25, Emil Velikov wrote:
> >>> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
> 
>  Quoting Emil Velikov (2018-12-03 07:54:38)
> > Hi all,
> >
> > On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
> > wrote:
> >>
> >> Hi all,
> >>
> >> I can see why people may opt to not use or maintain the autotools 
> >> build.
> >> Although I would kindly ask that we do not remove it just yet.
> >>
> >> In Mesa, we have different parts not used by different teams. As such
> >> we tend to remove stuff when nobody is around to maintain it anymore.
> >>
> >> That said, I'm planning to continue maintaining it and would appreciate
> >> if we keep it in-tree.
> >>
> >> As people may be concerned about bugreports and alike we can trivially
> >> add a warning (as configure is invoked) to forwards any issues to my
> >> email. Additionally (or alternatively) we can have an autotools 
> >> bugzilla
> >> category with me as the default assignee.
> >>
> >
> > Seems like I failed to make things clear enough with earlier message.
> >
> > There is _no_ expectation for anyone to touch or even look at autotools.
> > Hence, my suggestion to have configure.ac point people to me in case of 
> > issues.
> >
> > If people have CI that uses it - feel free to drop it.
> >
> 
>  I've tried to stay out of this discussion, because everyone knows my 
>  opinion,
>  and I feel I don't have much to add, however...
> 
> >
> > That said, many have asked why I'd go through the pain of maintaining 
> > it:
> >  - Most Linux distributions have switched, but there'still a few 
> > outstanding
> >  - Non Linux distributions have not switched
> 
>  Haiku has at least :)
> 
> >>> \o/
> >>
> >> And Debian too (in experimental). Ubuntu will follow once the final is
> >> out and it build everywhere. There's a build failure on ppc64el, btw:
> >>
> >> https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0
> >>
> >  - The meson build is missing features, relative the autotools one
> 
>  The only feature that I know that meson does not have relative to 
>  autotools is
>  the gl mangling stuff (which is intentional, we'll add it if someone 
>  shows up
>  with a need for it). Everything else is either intentionally not 
>  implemented
>  (GLX TLS toggling for example, which meson hardcodes on for OSes that 
>  support
>  it, and off for those that don't).
> 
> >>> On top of the TLS and symbol mangling (for which I agree) there is:
> >>>  - disable direct glx - non linux people use this
> >>
> >> This seems to work, at least on Hurd:
> >>
> >> diff --git a/meson.build b/meson.build
> >> index 33f4e5ad3cf..90cc0bb3af2 100644
> >> --- a/meson.build
> >> +++ b/meson.build
> >> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
> >>  with_valgrind = get_option('valgrind')
> >>  with_libunwind = get_option('libunwind')
> >>  with_asm = get_option('asm')
> >> +with_glx_direct= get_option('glx-direct')

There should be a space between t and =

> >>  with_glx_read_only_text = get_option('glx-read-only-text')
> >>  with_osmesa = get_option('osmesa')
> >>  with_swr_arches = get_option('swr-arches')
> >> @@ -370,9 +371,6 @@ if with_glvnd
> >>endif
> >>  endif
> >>
> >> -# TODO: toggle for this
> >> -with_glx_direct = true
> >> -
> >>  if with_vulkan_icd_dir == ''
> >>with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
> >>  endif
> >> diff --git a/meson_options.txt b/meson_options.txt
> >> index a1d5ab0e185..4d5f36bf33d 100644
> >> --- a/meson_options.txt
> >> +++ b/meson_options.txt
> >> @@ -205,6 +205,12 @@ option(
> >>choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
> >>description : 'Build support for GLX platform'
> >>  )
> >> +option(
> >> +  'glx-direct',
> >> +  type : 'boolean',
> >> +  value : 'true',
> >> +  description : 'Enable direct rendering in GLX and EGL for DRI'
> >> +)
> >>  option(
> >>'egl',
> >>type : 'combo',
> >>
> >>
> > 
> > I'm glad that this actually worked :) I tried to wire up direct glx so 
> > adding a
> > toggle would be easy if we needed it. Do you need this for Hurd Timo?
> 
> Yep, it also needs -D_GNU_SOURCE which hopefully is fixed by this:
> 
> --- a/meson.build
> +++ b/meson.build
> @@ -779,7 +779,7 @@ if cc.compiles('int foo(void) __attribut
>  endif
>  
>  # TODO: this is very incomplete
> -if ['linux', 'cygwin'].contains(host_machine.system())
> +if ['linux', 'linux-gnu', 'cygwin', 'gnu'].contains(host_machine.system())
>pre_args += '-D_GNU_SOURCE'
>  endif

Would you like to send those as patches and CC me on them, or would you like me
to send them and 

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 3.12.2018 20.54, Dylan Baker wrote:
> Quoting Timo Aaltonen (2018-12-03 10:36:12)
>> On 3.12.2018 20.25, Emil Velikov wrote:
>>> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:

 Quoting Emil Velikov (2018-12-03 07:54:38)
> Hi all,
>
> On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
> wrote:
>>
>> Hi all,
>>
>> I can see why people may opt to not use or maintain the autotools build.
>> Although I would kindly ask that we do not remove it just yet.
>>
>> In Mesa, we have different parts not used by different teams. As such
>> we tend to remove stuff when nobody is around to maintain it anymore.
>>
>> That said, I'm planning to continue maintaining it and would appreciate
>> if we keep it in-tree.
>>
>> As people may be concerned about bugreports and alike we can trivially
>> add a warning (as configure is invoked) to forwards any issues to my
>> email. Additionally (or alternatively) we can have an autotools bugzilla
>> category with me as the default assignee.
>>
>
> Seems like I failed to make things clear enough with earlier message.
>
> There is _no_ expectation for anyone to touch or even look at autotools.
> Hence, my suggestion to have configure.ac point people to me in case of 
> issues.
>
> If people have CI that uses it - feel free to drop it.
>

 I've tried to stay out of this discussion, because everyone knows my 
 opinion,
 and I feel I don't have much to add, however...

>
> That said, many have asked why I'd go through the pain of maintaining it:
>  - Most Linux distributions have switched, but there'still a few 
> outstanding
>  - Non Linux distributions have not switched

 Haiku has at least :)

>>> \o/
>>
>> And Debian too (in experimental). Ubuntu will follow once the final is
>> out and it build everywhere. There's a build failure on ppc64el, btw:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0
>>
>  - The meson build is missing features, relative the autotools one

 The only feature that I know that meson does not have relative to 
 autotools is
 the gl mangling stuff (which is intentional, we'll add it if someone shows 
 up
 with a need for it). Everything else is either intentionally not 
 implemented
 (GLX TLS toggling for example, which meson hardcodes on for OSes that 
 support
 it, and off for those that don't).

>>> On top of the TLS and symbol mangling (for which I agree) there is:
>>>  - disable direct glx - non linux people use this
>>
>> This seems to work, at least on Hurd:
>>
>> diff --git a/meson.build b/meson.build
>> index 33f4e5ad3cf..90cc0bb3af2 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
>>  with_valgrind = get_option('valgrind')
>>  with_libunwind = get_option('libunwind')
>>  with_asm = get_option('asm')
>> +with_glx_direct= get_option('glx-direct')
>>  with_glx_read_only_text = get_option('glx-read-only-text')
>>  with_osmesa = get_option('osmesa')
>>  with_swr_arches = get_option('swr-arches')
>> @@ -370,9 +371,6 @@ if with_glvnd
>>endif
>>  endif
>>
>> -# TODO: toggle for this
>> -with_glx_direct = true
>> -
>>  if with_vulkan_icd_dir == ''
>>with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
>>  endif
>> diff --git a/meson_options.txt b/meson_options.txt
>> index a1d5ab0e185..4d5f36bf33d 100644
>> --- a/meson_options.txt
>> +++ b/meson_options.txt
>> @@ -205,6 +205,12 @@ option(
>>choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
>>description : 'Build support for GLX platform'
>>  )
>> +option(
>> +  'glx-direct',
>> +  type : 'boolean',
>> +  value : 'true',
>> +  description : 'Enable direct rendering in GLX and EGL for DRI'
>> +)
>>  option(
>>'egl',
>>type : 'combo',
>>
>>
> 
> I'm glad that this actually worked :) I tried to wire up direct glx so adding 
> a
> toggle would be easy if we needed it. Do you need this for Hurd Timo?

Yep, it also needs -D_GNU_SOURCE which hopefully is fixed by this:

--- a/meson.build
+++ b/meson.build
@@ -779,7 +779,7 @@ if cc.compiles('int foo(void) __attribut
 endif
 
 # TODO: this is very incomplete
-if ['linux', 'cygwin'].contains(host_machine.system())
+if ['linux', 'linux-gnu', 'cygwin', 'gnu'].contains(host_machine.system())
   pre_args += '-D_GNU_SOURCE'
 endif

(to match configure.ac) 

And that ppc64el build fail might be because it for some reason doesn't seem to 
get -DUSE_PPC64LE_ASM..



-- 
t



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] Lets talk about autotools

[Dylan Baker]

Quoting Timo Aaltonen (2018-12-03 10:36:12)
> On 3.12.2018 20.25, Emil Velikov wrote:
> > On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
> >>
> >> Quoting Emil Velikov (2018-12-03 07:54:38)
> >>> Hi all,
> >>>
> >>> On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
> >>> wrote:
> 
>  Hi all,
> 
>  I can see why people may opt to not use or maintain the autotools build.
>  Although I would kindly ask that we do not remove it just yet.
> 
>  In Mesa, we have different parts not used by different teams. As such
>  we tend to remove stuff when nobody is around to maintain it anymore.
> 
>  That said, I'm planning to continue maintaining it and would appreciate
>  if we keep it in-tree.
> 
>  As people may be concerned about bugreports and alike we can trivially
>  add a warning (as configure is invoked) to forwards any issues to my
>  email. Additionally (or alternatively) we can have an autotools bugzilla
>  category with me as the default assignee.
> 
> >>>
> >>> Seems like I failed to make things clear enough with earlier message.
> >>>
> >>> There is _no_ expectation for anyone to touch or even look at autotools.
> >>> Hence, my suggestion to have configure.ac point people to me in case of 
> >>> issues.
> >>>
> >>> If people have CI that uses it - feel free to drop it.
> >>>
> >>
> >> I've tried to stay out of this discussion, because everyone knows my 
> >> opinion,
> >> and I feel I don't have much to add, however...
> >>
> >>>
> >>> That said, many have asked why I'd go through the pain of maintaining it:
> >>>  - Most Linux distributions have switched, but there'still a few 
> >>> outstanding
> >>>  - Non Linux distributions have not switched
> >>
> >> Haiku has at least :)
> >>
> > \o/
> 
> And Debian too (in experimental). Ubuntu will follow once the final is
> out and it build everywhere. There's a build failure on ppc64el, btw:
> 
> https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0
> 
> >>>  - The meson build is missing features, relative the autotools one
> >>
> >> The only feature that I know that meson does not have relative to 
> >> autotools is
> >> the gl mangling stuff (which is intentional, we'll add it if someone shows 
> >> up
> >> with a need for it). Everything else is either intentionally not 
> >> implemented
> >> (GLX TLS toggling for example, which meson hardcodes on for OSes that 
> >> support
> >> it, and off for those that don't).
> >>
> > On top of the TLS and symbol mangling (for which I agree) there is:
> >  - disable direct glx - non linux people use this
> 
> This seems to work, at least on Hurd:
> 
> diff --git a/meson.build b/meson.build
> index 33f4e5ad3cf..90cc0bb3af2 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
>  with_valgrind = get_option('valgrind')
>  with_libunwind = get_option('libunwind')
>  with_asm = get_option('asm')
> +with_glx_direct= get_option('glx-direct')
>  with_glx_read_only_text = get_option('glx-read-only-text')
>  with_osmesa = get_option('osmesa')
>  with_swr_arches = get_option('swr-arches')
> @@ -370,9 +371,6 @@ if with_glvnd
>endif
>  endif
> 
> -# TODO: toggle for this
> -with_glx_direct = true
> -
>  if with_vulkan_icd_dir == ''
>with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
>  endif
> diff --git a/meson_options.txt b/meson_options.txt
> index a1d5ab0e185..4d5f36bf33d 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -205,6 +205,12 @@ option(
>choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
>description : 'Build support for GLX platform'
>  )
> +option(
> +  'glx-direct',
> +  type : 'boolean',
> +  value : 'true',
> +  description : 'Enable direct rendering in GLX and EGL for DRI'
> +)
>  option(
>'egl',
>type : 'combo',
> 
> 

I'm glad that this actually worked :) I tried to wire up direct glx so adding a
toggle would be easy if we needed it. Do you need this for Hurd Timo?

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] Lets talk about autotools

[Dylan Baker]

Quoting Emil Velikov (2018-12-03 10:25:48)
> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-03 07:54:38)
> > > Hi all,
> > >
> > > On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I can see why people may opt to not use or maintain the autotools build.
> > > > Although I would kindly ask that we do not remove it just yet.
> > > >
> > > > In Mesa, we have different parts not used by different teams. As such
> > > > we tend to remove stuff when nobody is around to maintain it anymore.
> > > >
> > > > That said, I'm planning to continue maintaining it and would appreciate
> > > > if we keep it in-tree.
> > > >
> > > > As people may be concerned about bugreports and alike we can trivially
> > > > add a warning (as configure is invoked) to forwards any issues to my
> > > > email. Additionally (or alternatively) we can have an autotools bugzilla
> > > > category with me as the default assignee.
> > > >
> > >
> > > Seems like I failed to make things clear enough with earlier message.
> > >
> > > There is _no_ expectation for anyone to touch or even look at autotools.
> > > Hence, my suggestion to have configure.ac point people to me in case of 
> > > issues.
> > >
> > > If people have CI that uses it - feel free to drop it.
> > >
> >
> > I've tried to stay out of this discussion, because everyone knows my 
> > opinion,
> > and I feel I don't have much to add, however...
> >
> > >
> > > That said, many have asked why I'd go through the pain of maintaining it:
> > >  - Most Linux distributions have switched, but there'still a few 
> > > outstanding
> > >  - Non Linux distributions have not switched
> >
> > Haiku has at least :)
> >
> \o/
> 
> > >  - The meson build is missing features, relative the autotools one
> >
> > The only feature that I know that meson does not have relative to autotools 
> > is
> > the gl mangling stuff (which is intentional, we'll add it if someone shows 
> > up
> > with a need for it). Everything else is either intentionally not implemented
> > (GLX TLS toggling for example, which meson hardcodes on for OSes that 
> > support
> > it, and off for those that don't).
> >
> On top of the TLS and symbol mangling (for which I agree) there is:
> 
>  - no CrOS support

We've done the best we can to get chromeos running (all of the "android") stuff
is actually for chrome's android container. I've also fixed a number of meson
bugs for them, if there's more they need from us they need to let us know. It's
unfortunate that I don't have good contacts with Chrome people and Intel anymore
:/

>  - static/shared mesa (or at least parts of) - Kitware guys are still using it

No one has brought this up, this is actually the thing on the list I'm most
reluctant to enable, mostly because I don't understand the use case for building
OpenGL static, and there would be a lot of validation required to make sure
everything works correctly.

>  - non-static gallium targets - yes it's intentionally 'hidden' in 
> configure.ac

I'm happy to turn this on if there's a use case and someone who wants to
maintain and support this. My understanding was that there was a lot resistance
to use this feature as VMware didn't want this on windows and everyone else was
reluctant to add another "windows vs !windows" path.

>  - disable direct glx - non linux people use this

This is another one of those we'll add when someone asks, like the mangling
stuff. There were a number of features that when I started I asked about and the
consensus was "wait and see", if anyone needs it we'll add it.

> 
> I understand the reluctance on the latter two, yet leaving CrOS and
> Kitware in the cold seems strange.
> 
> > >  - I've been approached by individuals, who cannot quite yet use meson
> >
> > At this point we've been very clear of our intentions to move to meson, as 
> > Matt
> > said I have worked very hard to resolve any issues developers and users 
> > have had
> > (and have spent a lot of time booting VM's and fixing meson and mesa's meson
> > build on non-linux OSes) or reported, but we can't resolve issues that 
> > aren't
> > reported. If people are having issues using meson and they're not filing a 
> > bug
> > with meson or with mesa, or mailing the list, or getting on IRC, there is
> > nothing we can do for them, and at some point they need to speak up, or 
> > accept
> > things.
> >
> As the Mesa community grows, the amount of discussions/patches we
> produce is quite intimidating.

This is a good point.

Dylan

> Over the years, I've been reaching out to distributions and
> maintainers, many of which doing this as a hobby, to ease their mind.
> 
> Your point is valid - issues should be brought forward. Although
> without encouragement things are hard sometimes.
> 
> Thanks
> -Emil


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

Re: [Mesa-dev] Lets talk about autotools

[Kristian Høgsberg]

On Mon, Dec 3, 2018 at 10:28 AM Emil Velikov  wrote:
>
> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
> >
> > Quoting Emil Velikov (2018-12-03 07:54:38)
> > > Hi all,
> > >
> > > On Thu, 29 Nov 2018 at 17:44, Emil Velikov  
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I can see why people may opt to not use or maintain the autotools build.
> > > > Although I would kindly ask that we do not remove it just yet.
> > > >
> > > > In Mesa, we have different parts not used by different teams. As such
> > > > we tend to remove stuff when nobody is around to maintain it anymore.
> > > >
> > > > That said, I'm planning to continue maintaining it and would appreciate
> > > > if we keep it in-tree.
> > > >
> > > > As people may be concerned about bugreports and alike we can trivially
> > > > add a warning (as configure is invoked) to forwards any issues to my
> > > > email. Additionally (or alternatively) we can have an autotools bugzilla
> > > > category with me as the default assignee.
> > > >
> > >
> > > Seems like I failed to make things clear enough with earlier message.
> > >
> > > There is _no_ expectation for anyone to touch or even look at autotools.
> > > Hence, my suggestion to have configure.ac point people to me in case of 
> > > issues.
> > >
> > > If people have CI that uses it - feel free to drop it.
> > >
> >
> > I've tried to stay out of this discussion, because everyone knows my 
> > opinion,
> > and I feel I don't have much to add, however...
> >
> > >
> > > That said, many have asked why I'd go through the pain of maintaining it:
> > >  - Most Linux distributions have switched, but there'still a few 
> > > outstanding
> > >  - Non Linux distributions have not switched
> >
> > Haiku has at least :)
> >
> \o/
>
> > >  - The meson build is missing features, relative the autotools one
> >
> > The only feature that I know that meson does not have relative to autotools 
> > is
> > the gl mangling stuff (which is intentional, we'll add it if someone shows 
> > up
> > with a need for it). Everything else is either intentionally not implemented
> > (GLX TLS toggling for example, which meson hardcodes on for OSes that 
> > support
> > it, and off for those that don't).
> >
> On top of the TLS and symbol mangling (for which I agree) there is:
>
>  - no CrOS support
>  - static/shared mesa (or at least parts of) - Kitware guys are still using it
>  - non-static gallium targets - yes it's intentionally 'hidden' in 
> configure.ac
>  - disable direct glx - non linux people use this
>
> I understand the reluctance on the latter two, yet leaving CrOS and
> Kitware in the cold seems strange.

We're mostly ready to switch, Chad's done the work to update the
ebuilds and sdk. Don't keep autotools on account of us - excited to
see this work mature.

Kristian

>
> > >  - I've been approached by individuals, who cannot quite yet use meson
> >
> > At this point we've been very clear of our intentions to move to meson, as 
> > Matt
> > said I have worked very hard to resolve any issues developers and users 
> > have had
> > (and have spent a lot of time booting VM's and fixing meson and mesa's meson
> > build on non-linux OSes) or reported, but we can't resolve issues that 
> > aren't
> > reported. If people are having issues using meson and they're not filing a 
> > bug
> > with meson or with mesa, or mailing the list, or getting on IRC, there is
> > nothing we can do for them, and at some point they need to speak up, or 
> > accept
> > things.
> >
> As the Mesa community grows, the amount of discussions/patches we
> produce is quite intimidating.
>
> Over the years, I've been reaching out to distributions and
> maintainers, many of which doing this as a hobby, to ease their mind.
>
> Your point is valid - issues should be brought forward. Although
> without encouragement things are hard sometimes.
>
> Thanks
> -Emil
> ___
> 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] Lets talk about autotools

[Timo Aaltonen]

On 3.12.2018 20.25, Emil Velikov wrote:
> On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
>>
>> Quoting Emil Velikov (2018-12-03 07:54:38)
>>> Hi all,
>>>
>>> On Thu, 29 Nov 2018 at 17:44, Emil Velikov  wrote:

 Hi all,

 I can see why people may opt to not use or maintain the autotools build.
 Although I would kindly ask that we do not remove it just yet.

 In Mesa, we have different parts not used by different teams. As such
 we tend to remove stuff when nobody is around to maintain it anymore.

 That said, I'm planning to continue maintaining it and would appreciate
 if we keep it in-tree.

 As people may be concerned about bugreports and alike we can trivially
 add a warning (as configure is invoked) to forwards any issues to my
 email. Additionally (or alternatively) we can have an autotools bugzilla
 category with me as the default assignee.

>>>
>>> Seems like I failed to make things clear enough with earlier message.
>>>
>>> There is _no_ expectation for anyone to touch or even look at autotools.
>>> Hence, my suggestion to have configure.ac point people to me in case of 
>>> issues.
>>>
>>> If people have CI that uses it - feel free to drop it.
>>>
>>
>> I've tried to stay out of this discussion, because everyone knows my opinion,
>> and I feel I don't have much to add, however...
>>
>>>
>>> That said, many have asked why I'd go through the pain of maintaining it:
>>>  - Most Linux distributions have switched, but there'still a few outstanding
>>>  - Non Linux distributions have not switched
>>
>> Haiku has at least :)
>>
> \o/

And Debian too (in experimental). Ubuntu will follow once the final is
out and it build everywhere. There's a build failure on ppc64el, btw:

https://buildd.debian.org/status/fetch.php?pkg=mesa=ppc64el=18.3.0%7Erc5-1=1543575640=0

>>>  - The meson build is missing features, relative the autotools one
>>
>> The only feature that I know that meson does not have relative to autotools 
>> is
>> the gl mangling stuff (which is intentional, we'll add it if someone shows up
>> with a need for it). Everything else is either intentionally not implemented
>> (GLX TLS toggling for example, which meson hardcodes on for OSes that support
>> it, and off for those that don't).
>>
> On top of the TLS and symbol mangling (for which I agree) there is:
>  - disable direct glx - non linux people use this

This seems to work, at least on Hurd:

diff --git a/meson.build b/meson.build
index 33f4e5ad3cf..90cc0bb3af2 100644
--- a/meson.build
+++ b/meson.build
@@ -53,6 +53,7 @@ with_tests = get_option('build-tests')
 with_valgrind = get_option('valgrind')
 with_libunwind = get_option('libunwind')
 with_asm = get_option('asm')
+with_glx_direct= get_option('glx-direct')
 with_glx_read_only_text = get_option('glx-read-only-text')
 with_osmesa = get_option('osmesa')
 with_swr_arches = get_option('swr-arches')
@@ -370,9 +371,6 @@ if with_glvnd
   endif
 endif

-# TODO: toggle for this
-with_glx_direct = true
-
 if with_vulkan_icd_dir == ''
   with_vulkan_icd_dir = join_paths(get_option('datadir'), 'vulkan/icd.d')
 endif
diff --git a/meson_options.txt b/meson_options.txt
index a1d5ab0e185..4d5f36bf33d 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -205,6 +205,12 @@ option(
   choices : ['auto', 'disabled', 'dri', 'xlib', 'gallium-xlib'],
   description : 'Build support for GLX platform'
 )
+option(
+  'glx-direct',
+  type : 'boolean',
+  value : 'true',
+  description : 'Enable direct rendering in GLX and EGL for DRI'
+)
 option(
   'egl',
   type : 'combo',


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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

On Mon, 3 Dec 2018 at 17:49, Dylan Baker  wrote:
>
> Quoting Emil Velikov (2018-12-03 07:54:38)
> > Hi all,
> >
> > On Thu, 29 Nov 2018 at 17:44, Emil Velikov  wrote:
> > >
> > > Hi all,
> > >
> > > I can see why people may opt to not use or maintain the autotools build.
> > > Although I would kindly ask that we do not remove it just yet.
> > >
> > > In Mesa, we have different parts not used by different teams. As such
> > > we tend to remove stuff when nobody is around to maintain it anymore.
> > >
> > > That said, I'm planning to continue maintaining it and would appreciate
> > > if we keep it in-tree.
> > >
> > > As people may be concerned about bugreports and alike we can trivially
> > > add a warning (as configure is invoked) to forwards any issues to my
> > > email. Additionally (or alternatively) we can have an autotools bugzilla
> > > category with me as the default assignee.
> > >
> >
> > Seems like I failed to make things clear enough with earlier message.
> >
> > There is _no_ expectation for anyone to touch or even look at autotools.
> > Hence, my suggestion to have configure.ac point people to me in case of 
> > issues.
> >
> > If people have CI that uses it - feel free to drop it.
> >
>
> I've tried to stay out of this discussion, because everyone knows my opinion,
> and I feel I don't have much to add, however...
>
> >
> > That said, many have asked why I'd go through the pain of maintaining it:
> >  - Most Linux distributions have switched, but there'still a few outstanding
> >  - Non Linux distributions have not switched
>
> Haiku has at least :)
>
\o/

> >  - The meson build is missing features, relative the autotools one
>
> The only feature that I know that meson does not have relative to autotools is
> the gl mangling stuff (which is intentional, we'll add it if someone shows up
> with a need for it). Everything else is either intentionally not implemented
> (GLX TLS toggling for example, which meson hardcodes on for OSes that support
> it, and off for those that don't).
>
On top of the TLS and symbol mangling (for which I agree) there is:

 - no CrOS support
 - static/shared mesa (or at least parts of) - Kitware guys are still using it
 - non-static gallium targets - yes it's intentionally 'hidden' in configure.ac
 - disable direct glx - non linux people use this

I understand the reluctance on the latter two, yet leaving CrOS and
Kitware in the cold seems strange.

> >  - I've been approached by individuals, who cannot quite yet use meson
>
> At this point we've been very clear of our intentions to move to meson, as 
> Matt
> said I have worked very hard to resolve any issues developers and users have 
> had
> (and have spent a lot of time booting VM's and fixing meson and mesa's meson
> build on non-linux OSes) or reported, but we can't resolve issues that aren't
> reported. If people are having issues using meson and they're not filing a bug
> with meson or with mesa, or mailing the list, or getting on IRC, there is
> nothing we can do for them, and at some point they need to speak up, or accept
> things.
>
As the Mesa community grows, the amount of discussions/patches we
produce is quite intimidating.

Over the years, I've been reaching out to distributions and
maintainers, many of which doing this as a hobby, to ease their mind.

Your point is valid - issues should be brought forward. Although
without encouragement things are hard sometimes.

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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Dave Airlie (2018-11-30 12:16:10)
> 
> On Wed., 28 Nov. 2018, 03:06 Matt Turner  
> On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen  wrote:
> >
> > On 17.11.2018 6.04, Dylan Baker wrote:
> > > Quoting Dylan Baker (2018-09-17 09:44:07)
> > >> I feel like for !windows meson is in good enough shape at this point
> that we
> > >> can start having the discussion about deleting the autotools build.
> So, is there
> > >> anything left that autotools can do that meson cannot (that we
> actually want to
> > >> implement)? And, what is a reasonable time-table to remove the
> autotools build?
> > >> I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> > >> that it would work for them.
> > >>
> > >> Dylan
> > >
> > > Okay, time for an update on things and a chance to talk about what 
> else
> we need.
> > >
> > > Support for llvm-config (and any binary, actually) overriding has
> landed in
> > > meson, and will be present in the 0.49.0 release, which is due out
> December 9th.
> >
> > Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
> > get Mesa backports up until and including 20.0.x, so I wonder how
> > complex these required new features in meson are to be backported, or
> > perhaps easily worked around? Backporting a whole new version of meson
> > might not happen..
> 
> I understand the LTS concept, but what's the value in never upgrading
> something like a build tool like Meson? Yeah, new versions give a
> possibility of regressions, but with something evolving as quickly as
> Meson the version available in April 2018 becomes less useful for its
> intended purpose with each passing month...
> 
> 
> Is meson guaranteeing backwards compatibility? Will meson in 2 years build a
> package built with meson now?
> 
> If I have mesa and another package using meson 0.48, and I update meson to 
> 0.52
> will the other package still rebuild fine for things like security updates?
> 
> Dave.

We have backwards compatibility, how long we plan to have backwards
compatibility is something that there is no formal policy in place for. It would
probably be good for distro people to chime in with their needs. I doubt you'll
get 14 years of backwards compatibility (RHEL has a really long shelf life) I
can open an issue and give you a link if you'd like that.

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] Lets talk about autotools

[Dylan Baker]

Quoting Emil Velikov (2018-12-03 07:54:38)
> Hi all,
> 
> On Thu, 29 Nov 2018 at 17:44, Emil Velikov  wrote:
> >
> > Hi all,
> >
> > I can see why people may opt to not use or maintain the autotools build.
> > Although I would kindly ask that we do not remove it just yet.
> >
> > In Mesa, we have different parts not used by different teams. As such
> > we tend to remove stuff when nobody is around to maintain it anymore.
> >
> > That said, I'm planning to continue maintaining it and would appreciate
> > if we keep it in-tree.
> >
> > As people may be concerned about bugreports and alike we can trivially
> > add a warning (as configure is invoked) to forwards any issues to my
> > email. Additionally (or alternatively) we can have an autotools bugzilla
> > category with me as the default assignee.
> >
> 
> Seems like I failed to make things clear enough with earlier message.
> 
> There is _no_ expectation for anyone to touch or even look at autotools.
> Hence, my suggestion to have configure.ac point people to me in case of 
> issues.
> 
> If people have CI that uses it - feel free to drop it.
> 

I've tried to stay out of this discussion, because everyone knows my opinion,
and I feel I don't have much to add, however...

> 
> That said, many have asked why I'd go through the pain of maintaining it:
>  - Most Linux distributions have switched, but there'still a few outstanding
>  - Non Linux distributions have not switched

Haiku has at least :)

>  - The meson build is missing features, relative the autotools one

The only feature that I know that meson does not have relative to autotools is
the gl mangling stuff (which is intentional, we'll add it if someone shows up
with a need for it). Everything else is either intentionally not implemented
(GLX TLS toggling for example, which meson hardcodes on for OSes that support
it, and off for those that don't).

>  - I've been approached by individuals, who cannot quite yet use meson

At this point we've been very clear of our intentions to move to meson, as Matt
said I have worked very hard to resolve any issues developers and users have had
(and have spent a lot of time booting VM's and fixing meson and mesa's meson
build on non-linux OSes) or reported, but we can't resolve issues that aren't
reported. If people are having issues using meson and they're not filing a bug
with meson or with mesa, or mailing the list, or getting on IRC, there is
nothing we can do for them, and at some point they need to speak up, or accept
things.

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] Lets talk about autotools

[Emil Velikov]

Hi all,

On Thu, 29 Nov 2018 at 17:44, Emil Velikov  wrote:
>
> Hi all,
>
> I can see why people may opt to not use or maintain the autotools build.
> Although I would kindly ask that we do not remove it just yet.
>
> In Mesa, we have different parts not used by different teams. As such
> we tend to remove stuff when nobody is around to maintain it anymore.
>
> That said, I'm planning to continue maintaining it and would appreciate
> if we keep it in-tree.
>
> As people may be concerned about bugreports and alike we can trivially
> add a warning (as configure is invoked) to forwards any issues to my
> email. Additionally (or alternatively) we can have an autotools bugzilla
> category with me as the default assignee.
>

Seems like I failed to make things clear enough with earlier message.

There is _no_ expectation for anyone to touch or even look at autotools.
Hence, my suggestion to have configure.ac point people to me in case of issues.

If people have CI that uses it - feel free to drop it.


That said, many have asked why I'd go through the pain of maintaining it:
 - Most Linux distributions have switched, but there'still a few outstanding
 - Non Linux distributions have not switched
 - The meson build is missing features, relative the autotools one
 - I've been approached by individuals, who cannot quite yet use meson


That said, if you guys want to remove it - so be it.

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

Re: [Mesa-dev] Lets talk about autotools

[Jason Ekstrand]

On Fri, Nov 30, 2018 at 2:45 PM Matt Turner  wrote:

> On Fri, Nov 30, 2018 at 2:28 AM Gert Wollny  wrote:
> > Am Donnerstag, den 29.11.2018, 17:44 + schrieb Emil Velikov:
> > > Hi all,
> > >
> > > I can see why people may opt to not use or maintain the autotools
> > > build. Although I would kindly ask that we do not remove it just yet.
> >
> > I second that, I think the process of removing autotools should be a
> > two-step procedure. i.e. prior to ripping autotools support out there
> > should be one or two releases that deprecates it, e.g. by changing
> > configure that it (1) needs an extra flag to run, and (2) when run
> > without this flag it would just print a message about the meson build
> > system, the deprecation of autotools (making it clear when it will be
> > removed), and information how to still run autotools with this extra
> > flag. If qwe
> >
> > A rationale is that with a release that only has mesa there is a high
> > chance that people not directly involved with the project, and that
> > don't follow git but only use the releases hit corner cases when
> > building mesa that we or maintainers for distributions might not be
> > aware of. Still having something around that is known to work would be
> > good for them, so they can report a bug against the meson build system
> > and still get their work done by easily switching to the autotools for
> > the time being.
>
> I've been using Meson to build Mesa in Gentoo for a ~6 months now, and
> I've reported (and Dylan has fixed) a handful of corner case bugs.
> Dylan is super responsive, usually having a fix within a day. It's
> been great, really.
>
> And we've been discussing removing autotools for more than a year now.
>
> I think we've been plenty conservative and there's nothing to be
> gained / no problems to be avoided by delaying further. (And again, if
> someone comes out of the woodwork with a bug in the Meson build, Dylan
> will fix it within a day in my experience)
>

I fully agree.  If we wait another 6 months, someone will make exactly the
same argument because surely there's someone out there who hasn't tried out
meson yet.  The only way to force every one of our users to give meson a
try and report the last handful of bugs is to delete autotools from the
tree.  It's been very stable for some time now; let's just pull the trigger.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Matt Turner]

On Fri, Nov 30, 2018 at 2:28 AM Gert Wollny  wrote:
> Am Donnerstag, den 29.11.2018, 17:44 + schrieb Emil Velikov:
> > Hi all,
> >
> > I can see why people may opt to not use or maintain the autotools
> > build. Although I would kindly ask that we do not remove it just yet.
>
> I second that, I think the process of removing autotools should be a
> two-step procedure. i.e. prior to ripping autotools support out there
> should be one or two releases that deprecates it, e.g. by changing
> configure that it (1) needs an extra flag to run, and (2) when run
> without this flag it would just print a message about the meson build
> system, the deprecation of autotools (making it clear when it will be
> removed), and information how to still run autotools with this extra
> flag. If qwe
>
> A rationale is that with a release that only has mesa there is a high
> chance that people not directly involved with the project, and that
> don't follow git but only use the releases hit corner cases when
> building mesa that we or maintainers for distributions might not be
> aware of. Still having something around that is known to work would be
> good for them, so they can report a bug against the meson build system
> and still get their work done by easily switching to the autotools for
> the time being.

I've been using Meson to build Mesa in Gentoo for a ~6 months now, and
I've reported (and Dylan has fixed) a handful of corner case bugs.
Dylan is super responsive, usually having a fix within a day. It's
been great, really.

And we've been discussing removing autotools for more than a year now.

I think we've been plenty conservative and there's nothing to be
gained / no problems to be avoided by delaying further. (And again, if
someone comes out of the woodwork with a bug in the Meson build, Dylan
will fix it within a day in my experience)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Dave Airlie]

On Wed., 28 Nov. 2018, 03:06 Matt Turner  On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen  wrote:
> >
> > On 17.11.2018 6.04, Dylan Baker wrote:
> > > Quoting Dylan Baker (2018-09-17 09:44:07)
> > >> I feel like for !windows meson is in good enough shape at this point
> that we
> > >> can start having the discussion about deleting the autotools build.
> So, is there
> > >> anything left that autotools can do that meson cannot (that we
> actually want to
> > >> implement)? And, what is a reasonable time-table to remove the
> autotools build?
> > >> I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> > >> that it would work for them.
> > >>
> > >> Dylan
> > >
> > > Okay, time for an update on things and a chance to talk about what
> else we need.
> > >
> > > Support for llvm-config (and any binary, actually) overriding has
> landed in
> > > meson, and will be present in the 0.49.0 release, which is due out
> December 9th.
> >
> > Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
> > get Mesa backports up until and including 20.0.x, so I wonder how
> > complex these required new features in meson are to be backported, or
> > perhaps easily worked around? Backporting a whole new version of meson
> > might not happen..
>
> I understand the LTS concept, but what's the value in never upgrading
> something like a build tool like Meson? Yeah, new versions give a
> possibility of regressions, but with something evolving as quickly as
> Meson the version available in April 2018 becomes less useful for its
> intended purpose with each passing month...
>

Is meson guaranteeing backwards compatibility? Will meson in 2 years build
a package built with meson now?

If I have mesa and another package using meson 0.48, and I update meson to
0.52 will the other package still rebuild fine for things like security
updates?

Dave.

> ___
> 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] Lets talk about autotools

[Gert Wollny]

Hello all, 

Am Donnerstag, den 29.11.2018, 17:44 + schrieb Emil Velikov:
> Hi all,
> 
> I can see why people may opt to not use or maintain the autotools
> build. Although I would kindly ask that we do not remove it just yet.

I second that, I think the process of removing autotools should be a
two-step procedure. i.e. prior to ripping autotools support out there
should be one or two releases that deprecates it, e.g. by changing
configure that it (1) needs an extra flag to run, and (2) when run
without this flag it would just print a message about the meson build
system, the deprecation of autotools (making it clear when it will be
removed), and information how to still run autotools with this extra
flag. If qwe 

A rationale is that with a release that only has mesa there is a high
chance that people not directly involved with the project, and that
don't follow git but only use the releases hit corner cases when
building mesa that we or maintainers for distributions might not be
aware of. Still having something around that is known to work would be
good for them, so they can report a bug against the meson build system
and still get their work done by easily switching to the autotools for
the time being.

Best, 
Gert

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

Re: [Mesa-dev] Lets talk about autotools

[Pekka Paalanen]

On Thu, 29 Nov 2018 17:44:47 +
Emil Velikov  wrote:

> Hi all,
> 
> I can see why people may opt to not use or maintain the autotools build.
> Although I would kindly ask that we do not remove it just yet.
> 
> In Mesa, we have different parts not used by different teams. As such
> we tend to remove stuff when nobody is around to maintain it anymore.
> 
> That said, I'm planning to continue maintaining it and would appreciate
> if we keep it in-tree.
> 
> As people may be concerned about bugreports and alike we can trivially
> add a warning (as configure is invoked) to forwards any issues to my
> email. Additionally (or alternatively) we can have an autotools bugzilla
> category with me as the default assignee.
> 
> What do you guys think?

Hi Emil,

could you explain your motivation behind keeping the autotools build
around? It seems like the points you made earlier are mooted by now.

Do you intend to remove autotools build from all CI, so that you alone
will be the lone user of it, meaning that no other developer should
care about its existence at all?

Wanting to keep it in-tree does not sound like it, but I wanted to
confirm what your expectations are from other developers.


Thanks,
pq


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

Re: [Mesa-dev] Lets talk about autotools

[Matt Turner]

On Thu, Nov 29, 2018 at 5:49 PM Alex Deucher  wrote:
>
> On Thu, Nov 29, 2018 at 8:26 PM Eric Anholt  wrote:
> >
> > Emil Velikov  writes:
> >
> > > Hi all,
> > >
> > > I can see why people may opt to not use or maintain the autotools build.
> > > Although I would kindly ask that we do not remove it just yet.
> > >
> > > In Mesa, we have different parts not used by different teams. As such
> > > we tend to remove stuff when nobody is around to maintain it anymore.
> > >
> > > That said, I'm planning to continue maintaining it and would appreciate
> > > if we keep it in-tree.
> > >
> > > As people may be concerned about bugreports and alike we can trivially
> > > add a warning (as configure is invoked) to forwards any issues to my
> > > email. Additionally (or alternatively) we can have an autotools bugzilla
> > > category with me as the default assignee.
> > >
> > > What do you guys think?
> >
> > Strongly disagree.  We shouldn't be maintaining build systems for fun,
> > we should be doing the minimum amount of build system work to get our
> > actual work done quickly and reliably.
>
> If someone has a legitimate use for it and wants to maintain it, why
> not?  How is the build system any different than a specific feature in
> the project?

Restating what I said earlier, a build system is a means, not an end.
I would be sympathetic to someone wanting to maintain a driver for old
hardware because it's an end, but this is a build system that everyone
else is happy, scratch that, excited to be rid of.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Alex Deucher]

On Thu, Nov 29, 2018 at 9:19 PM Jason Ekstrand  wrote:
>
> On November 29, 2018 19:49:33 Alex Deucher  wrote:
>
> > On Thu, Nov 29, 2018 at 8:26 PM Eric Anholt  wrote:
> >>
> >> Emil Velikov  writes:
> >>
> >>> Hi all,
> >>>
> >>> I can see why people may opt to not use or maintain the autotools build.
> >>> Although I would kindly ask that we do not remove it just yet.
> >>>
> >>> In Mesa, we have different parts not used by different teams. As such
> >>> we tend to remove stuff when nobody is around to maintain it anymore.
> >>>
> >>> That said, I'm planning to continue maintaining it and would appreciate
> >>> if we keep it in-tree.
> >>>
> >>> As people may be concerned about bugreports and alike we can trivially
> >>> add a warning (as configure is invoked) to forwards any issues to my
> >>> email. Additionally (or alternatively) we can have an autotools bugzilla
> >>> category with me as the default assignee.
> >>>
> >>> What do you guys think?
> >>
> >> Strongly disagree.  We shouldn't be maintaining build systems for fun,
> >> we should be doing the minimum amount of build system work to get our
> >> actual work done quickly and reliably.
> >
> > If someone has a legitimate use for it and wants to maintain it, why
> > not?  How is the build system any different than a specific feature in
> > the project?
>
> Does it have a purpose?  I know it has a maintenance burden.  How is it
> different? As long as it exists, it is going to impose that maintenance
> burden on all of the developers in the project. As long as someone is using
> autotools to build Mesa (especially if that someone is a developer), we all
> have to keep it working.

I don't personally care one way or another on this, but it's
presumably has some purpose for him.  There are all sorts of aspects
of the project that are burdens for some and essential for others.

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

Re: [Mesa-dev] Lets talk about autotools

[Jason Ekstrand]

On November 29, 2018 19:49:33 Alex Deucher  wrote:


On Thu, Nov 29, 2018 at 8:26 PM Eric Anholt  wrote:


Emil Velikov  writes:


Hi all,

I can see why people may opt to not use or maintain the autotools build.
Although I would kindly ask that we do not remove it just yet.

In Mesa, we have different parts not used by different teams. As such
we tend to remove stuff when nobody is around to maintain it anymore.

That said, I'm planning to continue maintaining it and would appreciate
if we keep it in-tree.

As people may be concerned about bugreports and alike we can trivially
add a warning (as configure is invoked) to forwards any issues to my
email. Additionally (or alternatively) we can have an autotools bugzilla
category with me as the default assignee.

What do you guys think?


Strongly disagree.  We shouldn't be maintaining build systems for fun,
we should be doing the minimum amount of build system work to get our
actual work done quickly and reliably.


If someone has a legitimate use for it and wants to maintain it, why
not?  How is the build system any different than a specific feature in
the project?


Does it have a purpose?  I know it has a maintenance burden.  How is it 
different? As long as it exists, it is going to impose that maintenance 
burden on all of the developers in the project. As long as someone is using 
autotools to build Mesa (especially if that someone is a developer), we all 
have to keep it working.


--Jason


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

Re: [Mesa-dev] Lets talk about autotools

[Alex Deucher]

On Thu, Nov 29, 2018 at 8:26 PM Eric Anholt  wrote:
>
> Emil Velikov  writes:
>
> > Hi all,
> >
> > I can see why people may opt to not use or maintain the autotools build.
> > Although I would kindly ask that we do not remove it just yet.
> >
> > In Mesa, we have different parts not used by different teams. As such
> > we tend to remove stuff when nobody is around to maintain it anymore.
> >
> > That said, I'm planning to continue maintaining it and would appreciate
> > if we keep it in-tree.
> >
> > As people may be concerned about bugreports and alike we can trivially
> > add a warning (as configure is invoked) to forwards any issues to my
> > email. Additionally (or alternatively) we can have an autotools bugzilla
> > category with me as the default assignee.
> >
> > What do you guys think?
>
> Strongly disagree.  We shouldn't be maintaining build systems for fun,
> we should be doing the minimum amount of build system work to get our
> actual work done quickly and reliably.

If someone has a legitimate use for it and wants to maintain it, why
not?  How is the build system any different than a specific feature in
the project?

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

Re: [Mesa-dev] Lets talk about autotools

[Eric Anholt]

Emil Velikov  writes:

> Hi all,
>
> I can see why people may opt to not use or maintain the autotools build.
> Although I would kindly ask that we do not remove it just yet.
>
> In Mesa, we have different parts not used by different teams. As such
> we tend to remove stuff when nobody is around to maintain it anymore.
>
> That said, I'm planning to continue maintaining it and would appreciate
> if we keep it in-tree.
>
> As people may be concerned about bugreports and alike we can trivially
> add a warning (as configure is invoked) to forwards any issues to my
> email. Additionally (or alternatively) we can have an autotools bugzilla
> category with me as the default assignee.
>
> What do you guys think?

Strongly disagree.  We shouldn't be maintaining build systems for fun,
we should be doing the minimum amount of build system work to get our
actual work done quickly and reliably.


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] Lets talk about autotools

[Dylan Baker]

Quoting Timo Aaltonen (2018-11-29 10:33:30)
> On 29.11.2018 20.22, Matt Turner wrote:
> > On Thu, Nov 29, 2018 at 9:47 AM Emil Velikov  
> > wrote:
> >> In Mesa, we have different parts not used by different teams. As such
> >> we tend to remove stuff when nobody is around to maintain it anymore.
> > 
> > We drop things for that reason, but also when something is no longer
> > needed. I don't think autotools is needed. As far as I know all
> > distributions have switched to Meson quite some time ago. I just
> > removed the last version of Mesa from Gentoo that we were still
> > building with autotools.
> 
> FTR, I converted the Debian Mesa packaging to Meson today, and realized
> that the feature in the upcoming Meson is not needed at all by the
> packaging (it can find llvm-config-N.N just fine..). So I'm fine with
> removing autotools support :)

Yay! (meson LLVM integration maintainer here) we support both the Debian style
llvm-config-$version and FreeBSD style llvm-config$version. The only thing
you'll run into is it always tries to select the newest version, you need the
upcoming feature if you want to build against an older version of LLVM with a
newer version installed.

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] Lets talk about autotools

[Timo Aaltonen]

On 29.11.2018 20.22, Matt Turner wrote:
> On Thu, Nov 29, 2018 at 9:47 AM Emil Velikov  wrote:
>> In Mesa, we have different parts not used by different teams. As such
>> we tend to remove stuff when nobody is around to maintain it anymore.
> 
> We drop things for that reason, but also when something is no longer
> needed. I don't think autotools is needed. As far as I know all
> distributions have switched to Meson quite some time ago. I just
> removed the last version of Mesa from Gentoo that we were still
> building with autotools.

FTR, I converted the Debian Mesa packaging to Meson today, and realized
that the feature in the upcoming Meson is not needed at all by the
packaging (it can find llvm-config-N.N just fine..). So I'm fine with
removing autotools support :)


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

Re: [Mesa-dev] Lets talk about autotools

[Matt Turner]

On Thu, Nov 29, 2018 at 9:47 AM Emil Velikov  wrote:
> In Mesa, we have different parts not used by different teams. As such
> we tend to remove stuff when nobody is around to maintain it anymore.

We drop things for that reason, but also when something is no longer
needed. I don't think autotools is needed. As far as I know all
distributions have switched to Meson quite some time ago. I just
removed the last version of Mesa from Gentoo that we were still
building with autotools.

> That said, I'm planning to continue maintaining it and would appreciate
> if we keep it in-tree.

If it were a driver for some old hardware that you wanted to maintain
I would be sympathetic. But this is an enormous build system that is
going to increase overhead for everyone, and for unclear benefit.

FWIW, git stats on git rm `find -name Makefile.am` configure.ac are

 105 files changed, 10872 deletions(-)

and I bet that's not all that could be removed.

That's the same order of maginitude as nouveau vieux or classic
radeon, and a lot more overhead than both.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

Hi all,

I can see why people may opt to not use or maintain the autotools build.
Although I would kindly ask that we do not remove it just yet.

In Mesa, we have different parts not used by different teams. As such
we tend to remove stuff when nobody is around to maintain it anymore.

That said, I'm planning to continue maintaining it and would appreciate
if we keep it in-tree.

As people may be concerned about bugreports and alike we can trivially
add a warning (as configure is invoked) to forwards any issues to my
email. Additionally (or alternatively) we can have an autotools bugzilla
category with me as the default assignee.

What do you guys think?

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

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 27.11.2018 19.42, Eero Tamminen wrote:
> Hi,
> 
> On 27.11.2018 19.05, Matt Turner wrote:
>> On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen 
>> wrote:
>>> On 17.11.2018 6.04, Dylan Baker wrote:
 Quoting Dylan Baker (2018-09-17 09:44:07)
> I feel like for !windows meson is in good enough shape at this
> point that we
> can start having the discussion about deleting the autotools build.
> So, is there
> anything left that autotools can do that meson cannot (that we
> actually want to
> implement)? And, what is a reasonable time-table to remove the
> autotools build?
> I think we could reasonably remove it as soon as 18.3 if others
> felt confident
> that it would work for them.

 Okay, time for an update on things and a chance to talk about what
 else we need.

 Support for llvm-config (and any binary, actually) overriding has
 landed in
 meson, and will be present in the 0.49.0 release, which is due out
 December 9th.
>>>
>>> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
>>> get Mesa backports up until and including 20.0.x, so I wonder how
>>> complex these required new features in meson are to be backported, or
>>> perhaps easily worked around? Backporting a whole new version of meson
>>> might not happen..
>>
>> I understand the LTS concept, but what's the value in never upgrading
>> something like a build tool like Meson? Yeah, new versions give a
>> possibility of regressions, but with something evolving as quickly as
>> Meson the version available in April 2018 becomes less useful for its
>> intended purpose with each passing month...
> 
> Ubuntu has so called hardware enabling (HWE) packages, which provide
> newer versions of kernel, mesa and few other components for LTS, and
> a meta package(s) that pull those in. They're based on package versions
> tested in development versions of Ubuntu.
> 
> For example, relevant Ubuntu 18.10 packages would be available as
> HWE packages for 18.04 somewhere around February, according to
> preliminary Ubuntu kernel schedule.
> 
> Of the packages relevant to Mesa, 18.10 has for example:
> - kernel v4.18   (18.04 has v4.15)
> - LLVM v7.0  (18.04 has LLVM v6)
> - Meson v0.47.2  (18.04 has v0.45)
> 
> I don't know how much that 4 month gap (before new development
> distro release package versions become available in preceding LTS
> release as HW packages) fluctuates.

The backports are being prepared now, bionic-proposed has everything
needed by mesa 18.2.2 (last of the 18.2.x series will be provided
later), xserver and drivers will follow soon. 18.04.2 image will be out
in February '19, but having these in -proposed means the daily image
will use them and gives plenty of time for testing (over the holidays, heh).

Meson is not on the list of HWE backports, but as I said, it could be
backported as a separate source package for mesa to build-depend on if
necessary.


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

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 27.11.2018 19.05, Matt Turner wrote:
> On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen  wrote:
>>
>> On 17.11.2018 6.04, Dylan Baker wrote:
>>> Quoting Dylan Baker (2018-09-17 09:44:07)
 I feel like for !windows meson is in good enough shape at this point that 
 we
 can start having the discussion about deleting the autotools build. So, is 
 there
 anything left that autotools can do that meson cannot (that we actually 
 want to
 implement)? And, what is a reasonable time-table to remove the autotools 
 build?
 I think we could reasonably remove it as soon as 18.3 if others felt 
 confident
 that it would work for them.

 Dylan
>>>
>>> Okay, time for an update on things and a chance to talk about what else we 
>>> need.
>>>
>>> Support for llvm-config (and any binary, actually) overriding has landed in
>>> meson, and will be present in the 0.49.0 release, which is due out December 
>>> 9th.
>>
>> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
>> get Mesa backports up until and including 20.0.x, so I wonder how
>> complex these required new features in meson are to be backported, or
>> perhaps easily worked around? Backporting a whole new version of meson
>> might not happen..
> 
> I understand the LTS concept, but what's the value in never upgrading
> something like a build tool like Meson? Yeah, new versions give a
> possibility of regressions, but with something evolving as quickly as
> Meson the version available in April 2018 becomes less useful for its
> intended purpose with each passing month...

Fair enough, I'll just package a newer, renamed meson for mesa if necessary.


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

Re: [Mesa-dev] Lets talk about autotools

[Eero Tamminen]

Hi,

On 27.11.2018 19.05, Matt Turner wrote:

On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen  wrote:

On 17.11.2018 6.04, Dylan Baker wrote:

Quoting Dylan Baker (2018-09-17 09:44:07)

I feel like for !windows meson is in good enough shape at this point that we
can start having the discussion about deleting the autotools build. So, is there
anything left that autotools can do that meson cannot (that we actually want to
implement)? And, what is a reasonable time-table to remove the autotools build?
I think we could reasonably remove it as soon as 18.3 if others felt confident
that it would work for them.


Okay, time for an update on things and a chance to talk about what else we need.

Support for llvm-config (and any binary, actually) overriding has landed in
meson, and will be present in the 0.49.0 release, which is due out December 9th.


Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
get Mesa backports up until and including 20.0.x, so I wonder how
complex these required new features in meson are to be backported, or
perhaps easily worked around? Backporting a whole new version of meson
might not happen..


I understand the LTS concept, but what's the value in never upgrading
something like a build tool like Meson? Yeah, new versions give a
possibility of regressions, but with something evolving as quickly as
Meson the version available in April 2018 becomes less useful for its
intended purpose with each passing month...


Ubuntu has so called hardware enabling (HWE) packages, which provide
newer versions of kernel, mesa and few other components for LTS, and
a meta package(s) that pull those in. They're based on package versions
tested in development versions of Ubuntu.

For example, relevant Ubuntu 18.10 packages would be available as
HWE packages for 18.04 somewhere around February, according to
preliminary Ubuntu kernel schedule.

Of the packages relevant to Mesa, 18.10 has for example:
- kernel v4.18   (18.04 has v4.15)
- LLVM v7.0  (18.04 has LLVM v6)
- Meson v0.47.2  (18.04 has v0.45)

I don't know how much that 4 month gap (before new development
distro release package versions become available in preceding LTS
release as HW packages) fluctuates.

Timo?


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

Re: [Mesa-dev] Lets talk about autotools

[Matt Turner]

On Tue, Nov 27, 2018 at 1:13 AM Timo Aaltonen  wrote:
>
> On 17.11.2018 6.04, Dylan Baker wrote:
> > Quoting Dylan Baker (2018-09-17 09:44:07)
> >> I feel like for !windows meson is in good enough shape at this point that 
> >> we
> >> can start having the discussion about deleting the autotools build. So, is 
> >> there
> >> anything left that autotools can do that meson cannot (that we actually 
> >> want to
> >> implement)? And, what is a reasonable time-table to remove the autotools 
> >> build?
> >> I think we could reasonably remove it as soon as 18.3 if others felt 
> >> confident
> >> that it would work for them.
> >>
> >> Dylan
> >
> > Okay, time for an update on things and a chance to talk about what else we 
> > need.
> >
> > Support for llvm-config (and any binary, actually) overriding has landed in
> > meson, and will be present in the 0.49.0 release, which is due out December 
> > 9th.
>
> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
> get Mesa backports up until and including 20.0.x, so I wonder how
> complex these required new features in meson are to be backported, or
> perhaps easily worked around? Backporting a whole new version of meson
> might not happen..

I understand the LTS concept, but what's the value in never upgrading
something like a build tool like Meson? Yeah, new versions give a
possibility of regressions, but with something evolving as quickly as
Meson the version available in April 2018 becomes less useful for its
intended purpose with each passing month...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 27.11.2018 12.20, Erik Faye-Lund wrote:
> On Tue, 2018-11-27 at 11:13 +0200, Timo Aaltonen wrote:
>> On 17.11.2018 6.04, Dylan Baker wrote:
>>> Quoting Dylan Baker (2018-09-17 09:44:07)
 I feel like for !windows meson is in good enough shape at this
 point that we
 can start having the discussion about deleting the autotools
 build. So, is there
 anything left that autotools can do that meson cannot (that we
 actually want to
 implement)? And, what is a reasonable time-table to remove the
 autotools build?
 I think we could reasonably remove it as soon as 18.3 if others
 felt confident
 that it would work for them.

 Dylan
>>>
>>> Okay, time for an update on things and a chance to talk about what
>>> else we need.
>>>
>>> Support for llvm-config (and any binary, actually) overriding has
>>> landed in
>>> meson, and will be present in the 0.49.0 release, which is due out
>>> December 9th.
>>
>> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and
>> will
>> get Mesa backports up until and including 20.0.x, so I wonder how
>> complex these required new features in meson are to be backported, or
>> perhaps easily worked around? Backporting a whole new version of
>> meson
>> might not happen..
>>
> 
> I don't know if this is acceptable or not for packaging, but one could
> always install meson from pip, I would assume...

Nope, network resources aren't available (nor allowed) when building for
the distro.


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

Re: [Mesa-dev] Lets talk about autotools

[Erik Faye-Lund]

On Tue, 2018-11-27 at 11:13 +0200, Timo Aaltonen wrote:
> On 17.11.2018 6.04, Dylan Baker wrote:
> > Quoting Dylan Baker (2018-09-17 09:44:07)
> > > I feel like for !windows meson is in good enough shape at this
> > > point that we
> > > can start having the discussion about deleting the autotools
> > > build. So, is there
> > > anything left that autotools can do that meson cannot (that we
> > > actually want to
> > > implement)? And, what is a reasonable time-table to remove the
> > > autotools build?
> > > I think we could reasonably remove it as soon as 18.3 if others
> > > felt confident
> > > that it would work for them.
> > > 
> > > Dylan
> > 
> > Okay, time for an update on things and a chance to talk about what
> > else we need.
> > 
> > Support for llvm-config (and any binary, actually) overriding has
> > landed in
> > meson, and will be present in the 0.49.0 release, which is due out
> > December 9th.
> 
> Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and
> will
> get Mesa backports up until and including 20.0.x, so I wonder how
> complex these required new features in meson are to be backported, or
> perhaps easily worked around? Backporting a whole new version of
> meson
> might not happen..
> 

I don't know if this is acceptable or not for packaging, but one could
always install meson from pip, I would assume...

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

Re: [Mesa-dev] Lets talk about autotools

[Timo Aaltonen]

On 17.11.2018 6.04, Dylan Baker wrote:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is 
>> there
>> anything left that autotools can do that meson cannot (that we actually want 
>> to
>> implement)? And, what is a reasonable time-table to remove the autotools 
>> build?
>> I think we could reasonably remove it as soon as 18.3 if others felt 
>> confident
>> that it would work for them.
>>
>> Dylan
> 
> Okay, time for an update on things and a chance to talk about what else we 
> need.
> 
> Support for llvm-config (and any binary, actually) overriding has landed in
> meson, and will be present in the 0.49.0 release, which is due out December 
> 9th.

Hi, just a note that Ubuntu 18.04 LTS ships with meson 0.45.1 and will
get Mesa backports up until and including 20.0.x, so I wonder how
complex these required new features in meson are to be backported, or
perhaps easily worked around? Backporting a whole new version of meson
might not happen..



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

Re: [Mesa-dev] Lets talk about autotools

[Eric Anholt]

Ian Romanick  writes:

> On 11/26/2018 03:44 PM, Marek Olšák wrote:
>> I don't run meson. I have a script that runs meson. I want to just run
>> the script and I want to it configure or reconfigure.
>> 
>> I don't want to add this failure path into my script: "meson ... ||
>> meson --reconfigure ..."
>
> I have a similar build script.  In my particular, weird setup I've had
> something like this since forever:
>
> if [ -d $BUILD_DIR ]; then
> meson --reconfigure ...
> else
> meson ...
> fi
>
> I even had to do some junk like that in the autotools days.  I'd love to
> have something better. :(

Agreed with this being an irritating feature of meson.


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] Lets talk about autotools

[Ian Romanick]

On 11/26/2018 03:44 PM, Marek Olšák wrote:
> I don't run meson. I have a script that runs meson. I want to just run
> the script and I want to it configure or reconfigure.
> 
> I don't want to add this failure path into my script: "meson ... ||
> meson --reconfigure ..."

I have a similar build script.  In my particular, weird setup I've had
something like this since forever:

if [ -d $BUILD_DIR ]; then
meson --reconfigure ...
else
meson ...
fi

I even had to do some junk like that in the autotools days.  I'd love to
have something better. :(

> Marek
> 
> On Mon, Nov 26, 2018 at 6:36 PM Dylan Baker  > wrote:
> 
> You mean you want to change the driver list?
> 
> meson builddir
> meson configure builddir -Ddri-drivers= -Dvulkan-drivers=
> -Dgallium-drivers=radeonsi
> ninja -C builddir  # which will trigger a reconfigure
> 
> Or was there something else you are trying to do?
> 
> Dylan
> 
> Quoting Marek Olšák (2018-11-26 15:29:40)
> > meson has a design defect that annoys me. I have a configure
> script. If I want
> > to change enabled drivers and run meson, it won't configure
> because the
> > directory exists, even if the meson parameters are different. I
> have to add
> > --reconfigure manually into the script. If I keep --reconfigure in
> the script
> > and the build directory doesn't exist, it doesn't configure.
> >
> > There has to be a better solution than "meson ... || meson
> --reconfigure ...".
> >
> > Marek
> >
> > On Mon, Sep 17, 2018 at 12:46 PM Dylan Baker  > wrote:
> >
> >     I feel like for !windows meson is in good enough shape at this
> point that
> >     we
> >     can start having the discussion about deleting the autotools
> build. So, is
> >     there
> >     anything left that autotools can do that meson cannot (that we
> actually
> >     want to
> >     implement)? And, what is a reasonable time-table to remove the
> autotools
> >     build?
> >     I think we could reasonably remove it as soon as 18.3 if
> others felt
> >     confident
> >     that it would work for them.
> >
> >     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
> 

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

Re: [Mesa-dev] Lets talk about autotools

[Marek Olšák]

I don't run meson. I have a script that runs meson. I want to just run the
script and I want to it configure or reconfigure.

I don't want to add this failure path into my script: "meson ... || meson
--reconfigure ..."

Marek

On Mon, Nov 26, 2018 at 6:36 PM Dylan Baker  wrote:

> You mean you want to change the driver list?
>
> meson builddir
> meson configure builddir -Ddri-drivers= -Dvulkan-drivers=
> -Dgallium-drivers=radeonsi
> ninja -C builddir  # which will trigger a reconfigure
>
> Or was there something else you are trying to do?
>
> Dylan
>
> Quoting Marek Olšák (2018-11-26 15:29:40)
> > meson has a design defect that annoys me. I have a configure script. If
> I want
> > to change enabled drivers and run meson, it won't configure because the
> > directory exists, even if the meson parameters are different. I have to
> add
> > --reconfigure manually into the script. If I keep --reconfigure in the
> script
> > and the build directory doesn't exist, it doesn't configure.
> >
> > There has to be a better solution than "meson ... || meson --reconfigure
> ...".
> >
> > Marek
> >
> > On Mon, Sep 17, 2018 at 12:46 PM Dylan Baker 
> wrote:
> >
> > I feel like for !windows meson is in good enough shape at this point
> that
> > we
> > can start having the discussion about deleting the autotools build.
> So, is
> > there
> > anything left that autotools can do that meson cannot (that we
> actually
> > want to
> > implement)? And, what is a reasonable time-table to remove the
> autotools
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt
> > confident
> > that it would work for them.
> >
> > 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] Lets talk about autotools

[Dylan Baker]

You mean you want to change the driver list?

meson builddir
meson configure builddir -Ddri-drivers= -Dvulkan-drivers= 
-Dgallium-drivers=radeonsi
ninja -C builddir  # which will trigger a reconfigure

Or was there something else you are trying to do?

Dylan

Quoting Marek Olšák (2018-11-26 15:29:40)
> meson has a design defect that annoys me. I have a configure script. If I want
> to change enabled drivers and run meson, it won't configure because the
> directory exists, even if the meson parameters are different. I have to add
> --reconfigure manually into the script. If I keep --reconfigure in the script
> and the build directory doesn't exist, it doesn't configure.
> 
> There has to be a better solution than "meson ... || meson --reconfigure ...".
> 
> Marek
> 
> On Mon, Sep 17, 2018 at 12:46 PM Dylan Baker  wrote:
> 
> I feel like for !windows meson is in good enough shape at this point that
> we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (that we actually
> want to
> implement)? And, what is a reasonable time-table to remove the autotools
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> that it would work for them.
> 
> 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] Lets talk about autotools

[Marek Olšák]

meson has a design defect that annoys me. I have a configure script. If I
want to change enabled drivers and run meson, it won't configure because
the directory exists, even if the meson parameters are different. I have to
add --reconfigure manually into the script. If I keep --reconfigure in the
script and the build directory doesn't exist, it doesn't configure.

There has to be a better solution than "meson ... || meson --reconfigure
...".

Marek

On Mon, Sep 17, 2018 at 12:46 PM Dylan Baker  wrote:

> I feel like for !windows meson is in good enough shape at this point that
> we
> can start having the discussion about deleting the autotools build. So, is
> there
> anything left that autotools can do that meson cannot (that we actually
> want to
> implement)? And, what is a reasonable time-table to remove the autotools
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> that it would work for them.
>
> 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] Lets talk about autotools

[Dylan Baker]

The VA-API state tracker has been fixed, that was a bug.

For wayland, I'm not sure what the right thing to do is. The autotools build is
equally rigid compared to meson, but it only enables surfaceless and x11 by
default on Linux and *BSD, meson enables wayland and drm as well.

I think we can make the auto platforms more auto when you use the auto option.

Dylan

Quoting Chuck Atkins (2018-11-26 12:53:24)
> Was there any conclusion on the idea of "auto" in having the build try to 
> adapt
> to your systems by default instead of just assuming a configuration?  That's
> the biggest issue I see at the momemt; for many options the current auto-tools
> build tries to adapt to your system and for the most part does an okay job, 
> the
> meson build does not.
> 
> 
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
> 
> 
> On Fri, Nov 23, 2018 at 8:46 PM Marek Olšák  wrote:
> 
> On Fri, Nov 16, 2018 at 11:05 PM Dylan Baker  wrote:
> 
> Quoting Dylan Baker (2018-09-17 09:44:07)
> > I feel like for !windows meson is in good enough shape at this point
> that we
> > can start having the discussion about deleting the autotools build.
> So, is there
> > anything left that autotools can do that meson cannot (that we
> actually want to
> > implement)? And, what is a reasonable time-table to remove the
> autotools build?
> > I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> > that it would work for them.
> >
> > Dylan
> 
> Okay, time for an update on things and a chance to talk about what 
> else
> we need.
> 
> Support for llvm-config (and any binary, actually) overriding has
> landed in
> meson, and will be present in the 0.49.0 release, which is due out
> December 9th.
> support for ICC has improved a great deal already, and I have a series
> here:
> https://github.com/mesonbuild/meson/pull/4359 (which may unfortunately
> not
> land until after 0.49) which should get ICC into pretty good shape on
> Linux and
> Mac, including actually checking that arguments are understood (which
> should
> allow us to drop the prefix test from SWR). I have some ideas on how 
> we
> might
> remove auto options, some of them can already use meson's "feature"
> https://mesonbuild.com/Build-options.html#features option (which 
> should
> make
> distro packagers happy too), for arch and OS specific options I have
> some ideas
> and I'll continue following up with those upstream.
> 
> For those interested in llvm-config overriding, with meson out of git
> you can
> add a files like:
> 
> $ cat ~/.local/share/meson/native/llvm-6.0
> [binaries]
> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
> 
> and invoke meson with:
> meson builddir --native-file llvm-6.0
> 
> which will configure with the specified llvm-config, and remember the
> llvm-config used on subsequent reconfigurations. You can override all
> binaries
> from a native file as well, so if you want to use a specific python3 
> or
> compiler you can do that, and you can load multiple native files in a
> single
> invocation.
> 
> Is there anything else we're missing in meson to be able to drop
> autotools?
> 
> 
> Everything seems OK here.
> 
> Marek
> ___
> 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] Lets talk about autotools

[Chuck Atkins]

Was there any conclusion on the idea of "auto" in having the build try to
adapt to your systems by default instead of just assuming a configuration?
That's the biggest issue I see at the momemt; for many options the current
auto-tools build tries to adapt to your system and for the most part does
an okay job, the meson build does not.


--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Fri, Nov 23, 2018 at 8:46 PM Marek Olšák  wrote:

> On Fri, Nov 16, 2018 at 11:05 PM Dylan Baker  wrote:
>
>> Quoting Dylan Baker (2018-09-17 09:44:07)
>> > I feel like for !windows meson is in good enough shape at this point
>> that we
>> > can start having the discussion about deleting the autotools build. So,
>> is there
>> > anything left that autotools can do that meson cannot (that we actually
>> want to
>> > implement)? And, what is a reasonable time-table to remove the
>> autotools build?
>> > I think we could reasonably remove it as soon as 18.3 if others felt
>> confident
>> > that it would work for them.
>> >
>> > Dylan
>>
>> Okay, time for an update on things and a chance to talk about what else
>> we need.
>>
>> Support for llvm-config (and any binary, actually) overriding has landed
>> in
>> meson, and will be present in the 0.49.0 release, which is due out
>> December 9th.
>> support for ICC has improved a great deal already, and I have a series
>> here:
>> https://github.com/mesonbuild/meson/pull/4359 (which may unfortunately
>> not
>> land until after 0.49) which should get ICC into pretty good shape on
>> Linux and
>> Mac, including actually checking that arguments are understood (which
>> should
>> allow us to drop the prefix test from SWR). I have some ideas on how we
>> might
>> remove auto options, some of them can already use meson's "feature"
>> https://mesonbuild.com/Build-options.html#features option (which should
>> make
>> distro packagers happy too), for arch and OS specific options I have some
>> ideas
>> and I'll continue following up with those upstream.
>>
>> For those interested in llvm-config overriding, with meson out of git you
>> can
>> add a files like:
>>
>> $ cat ~/.local/share/meson/native/llvm-6.0
>> [binaries]
>> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
>>
>> and invoke meson with:
>> meson builddir --native-file llvm-6.0
>>
>> which will configure with the specified llvm-config, and remember the
>> llvm-config used on subsequent reconfigurations. You can override all
>> binaries
>> from a native file as well, so if you want to use a specific python3 or
>> compiler you can do that, and you can load multiple native files in a
>> single
>> invocation.
>>
>> Is there anything else we're missing in meson to be able to drop
>> autotools?
>>
>
> Everything seems OK here.
>
> Marek
> ___
> 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] Lets talk about autotools

[Marek Olšák]

On Fri, Nov 16, 2018 at 11:05 PM Dylan Baker  wrote:

> Quoting Dylan Baker (2018-09-17 09:44:07)
> > I feel like for !windows meson is in good enough shape at this point
> that we
> > can start having the discussion about deleting the autotools build. So,
> is there
> > anything left that autotools can do that meson cannot (that we actually
> want to
> > implement)? And, what is a reasonable time-table to remove the autotools
> build?
> > I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> > that it would work for them.
> >
> > Dylan
>
> Okay, time for an update on things and a chance to talk about what else we
> need.
>
> Support for llvm-config (and any binary, actually) overriding has landed in
> meson, and will be present in the 0.49.0 release, which is due out
> December 9th.
> support for ICC has improved a great deal already, and I have a series
> here:
> https://github.com/mesonbuild/meson/pull/4359 (which may unfortunately not
> land until after 0.49) which should get ICC into pretty good shape on
> Linux and
> Mac, including actually checking that arguments are understood (which
> should
> allow us to drop the prefix test from SWR). I have some ideas on how we
> might
> remove auto options, some of them can already use meson's "feature"
> https://mesonbuild.com/Build-options.html#features option (which should
> make
> distro packagers happy too), for arch and OS specific options I have some
> ideas
> and I'll continue following up with those upstream.
>
> For those interested in llvm-config overriding, with meson out of git you
> can
> add a files like:
>
> $ cat ~/.local/share/meson/native/llvm-6.0
> [binaries]
> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
>
> and invoke meson with:
> meson builddir --native-file llvm-6.0
>
> which will configure with the specified llvm-config, and remember the
> llvm-config used on subsequent reconfigurations. You can override all
> binaries
> from a native file as well, so if you want to use a specific python3 or
> compiler you can do that, and you can load multiple native files in a
> single
> invocation.
>
> Is there anything else we're missing in meson to be able to drop autotools?
>

Everything seems OK here.

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

Re: [Mesa-dev] Lets talk about autotools

[Timothy Arceri]

One thing I always go to the autoconfig webpage for is to copy and paste 
the line for a 32bit cross-compiled mesa build.


It would be good if someone could document the method for cross 
compiling on the meson page before we remove autotools.


[1] https://www.mesa3d.org/autoconf.html

On 18/9/18 2:44 am, Dylan Baker wrote:

I feel like for !windows meson is in good enough shape at this point that we
can start having the discussion about deleting the autotools build. So, is there
anything left that autotools can do that meson cannot (that we actually want to
implement)? And, what is a reasonable time-table to remove the autotools build?
I think we could reasonably remove it as soon as 18.3 if others felt confident
that it would work for them.

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] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 19.11.18 20:02:
> Sorry, cell phones are really bad for responding to email...

no worries.

> The file has the same rules as cross files, it can be a local file, passed as 
> an
> absolute path, or read from $XDG directories (local files will be read before
> XDG ones).

That sounds workable then. I might have preferred a simple option/flag on the
CLI, but this works as well.

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] Lets talk about autotools

[Dylan Baker]

Quoting Gert Wollny (2018-11-18 02:56:00)
> Am Freitag, den 16.11.2018, 20:04 -0800 schrieb Dylan Baker:
> > 
> > Is there anything else we're missing in meson to be able to drop
> > autotools?
> 
> One thing that I notes is that it seems to be impossible to run the
> test suite for just one subdirectory because the only way to run the
> build is from the binary root directory. With autotools, when I do some
> work on a sub-module (like I did with mesa/st) I can just go there and
> run make check on the few tests that are there where I actually change
> code, with meson/ninja this doesn't seem to be possible and I have to
> either run the  full test suite, or run the test executables manually. 
> 
> One workaround I found on stack overflow [1] would be to give the
> test suites in these subdirectories different names so that one can
> then run e.g. 'ninja test.mesa.st' (the example there is using cmake as
> a basis to create the build.ninja file though). 
> 
> Another think I noted  - and I'm not sure  whether this is a feature or
> a bug - is that if CFLAG or CXXFLAGS are set in the environment, then
> it seems that the flags that should be added by the buildtype are
> ignored (Usually it turns out that -DDEBUG is missing, even though I
> selected debug or debugoptimized as build type).

That seems bad, I'll look into that very soon.

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] Lets talk about autotools

[Dylan Baker]

Quoting Gert Wollny (2018-11-18 02:56:00)
> Am Freitag, den 16.11.2018, 20:04 -0800 schrieb Dylan Baker:
> > 
> > Is there anything else we're missing in meson to be able to drop
> > autotools?
> 
> One thing that I notes is that it seems to be impossible to run the
> test suite for just one subdirectory because the only way to run the
> build is from the binary root directory. With autotools, when I do some
> work on a sub-module (like I did with mesa/st) I can just go there and
> run make check on the few tests that are there where I actually change
> code, with meson/ninja this doesn't seem to be possible and I have to
> either run the  full test suite, or run the test executables manually. 
> 
> One workaround I found on stack overflow [1] would be to give the
> test suites in these subdirectories different names so that one can
> then run e.g. 'ninja test.mesa.st' (the example there is using cmake as
> a basis to create the build.ninja file though). 

meson supports test suites, I'll send a patch to add them. You don't get quite
as nice of a target name, but you can use `meson test -C builddir --suite
$suite` to run just tests from a specfic suite. I'll send out a patch to add
our tests to suites.

> 
> Another think I noted  - and I'm not sure  whether this is a feature or
> a bug - is that if CFLAG or CXXFLAGS are set in the environment, then
> it seems that the flags that should be added by the buildtype are
> ignored (Usually it turns out that -DDEBUG is missing, even though I
> selected debug or debugoptimized as build type).
> 
> Best, 
> Gert
> 
> https://stackoverflow.com/questions/28636295/ninja-equivalent-of-makes-
> build-from-this-directory-down-feature-with-cmake
> 
> 
> 
> 
> 
> 
> > 
> > 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] Lets talk about autotools

[Dylan Baker]

Sorry, cell phones are really bad for responding to email...

The file has the same rules as cross files, it can be a local file, passed as an
absolute path, or read from $XDG directories (local files will be read before
XDG ones).

Dylan

Quoting Dylan Baker (2018-11-18 09:01:27)
> That file can live anywhere and can be referenced by absolute path.
> 
> On November 17, 2018 9:15:20 AM PST, "Kai Wasserbäch"
>  wrote:
> 
> Hey Dylan,
> Dylan Baker wrote on 17.11.18 05:04:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>  I feel like for !windows meson is in good enough shape at this 
> point that we
>  can start having the discussion about deleting the autotools 
> build. So, is there
>  anything left that autotools can do that meson cannot (that we 
> actually want to
>  implement)? And, what is a reasonable time-table to remove the 
> autotools build?
>  I think we could reasonably remove it as soon as 18.3 if others 
> felt confident
>  that it would work for them.
> 
>  Dylan
> 
> Okay, time for an update on things and a chance to talk about what 
> else we need.
> 
> Support for llvm-config (and any binary, actually) overriding has 
> landed in
> meson, and will be present in the 0.49.0 release, which is due out 
> December 9th.
> support for ICC has improved a great deal already, and I have a 
> series here:
> https://github.com/mesonbuild/meson/pull/4359 (which may 
> unfortunately not
> land until after 0.49) which should get ICC into pretty good shape on 
> Linux and
> Mac, including actually checking that arguments are understood (which 
> should
> allow us to drop the prefix test from SWR). I have some ideas on how 
> we might
> remove auto options, some of them can already use meson's "feature"
> https://mesonbuild.com/Build-options.html#features option (which 
> should make
> distro packagers happy too), for arch and OS specific options I have 
> some ideas
> and I'll continue following up with those upstream.
> 
> For those interested in llvm-config overriding, with meson out of git 
> you can
> add a files like:
> 
> $ cat ~/.local/share/meson/native/llvm-6.0
> [binaries]
> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
> 
> and invoke meson with:
> meson builddir --native-file llvm-6.0
> 
> which will configure with the specified llvm-config, and remember the
> llvm-config used on subsequent reconfigurations. You can override all 
> binaries
> from a native file as well, so if you want to use a specific python3 
> or
> compiler you can do that, and you can load multiple native files in a 
> single
> invocation.
> 
> do I understand that correctly as "there is no way to set this on the 
> command
> line"? Ie. something like
>   meson 
> --override-native="llvm-config=/usr/local/lib/llvm-6/bin/llvm-config"
> or something similar? I need to have a file in 
> $XDG_DATA_HOME/meson/native? That
> would be really ugly for (automatic) package build environments IMHO, 
> especially
> if you want to have reproducible builds. Could these files at least be 
> put in
> eg. the debian directory of a source package and then I could pass some 
> option
> to meson to look there for these overrides?
> 
> Cheers,
> Kai
> 
> 


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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

That file can live anywhere and can be referenced by absolute path.

On November 17, 2018 9:15:20 AM PST, "Kai Wasserbäch" 
 wrote:
>Hey Dylan,
>Dylan Baker wrote on 17.11.18 05:04:
>> Quoting Dylan Baker (2018-09-17 09:44:07)
>>> I feel like for !windows meson is in good enough shape at this point
>that we
>>> can start having the discussion about deleting the autotools build.
>So, is there
>>> anything left that autotools can do that meson cannot (that we
>actually want to
>>> implement)? And, what is a reasonable time-table to remove the
>autotools build?
>>> I think we could reasonably remove it as soon as 18.3 if others felt
>confident
>>> that it would work for them.
>>>
>>> Dylan
>> 
>> Okay, time for an update on things and a chance to talk about what
>else we need.
>> 
>> Support for llvm-config (and any binary, actually) overriding has
>landed in
>> meson, and will be present in the 0.49.0 release, which is due out
>December 9th.
>> support for ICC has improved a great deal already, and I have a
>series here:
>> https://github.com/mesonbuild/meson/pull/4359 (which may
>unfortunately not
>> land until after 0.49) which should get ICC into pretty good shape on
>Linux and
>> Mac, including actually checking that arguments are understood (which
>should
>> allow us to drop the prefix test from SWR). I have some ideas on how
>we might
>> remove auto options, some of them can already use meson's "feature"
>> https://mesonbuild.com/Build-options.html#features option (which
>should make
>> distro packagers happy too), for arch and OS specific options I have
>some ideas
>> and I'll continue following up with those upstream.
>> 
>> For those interested in llvm-config overriding, with meson out of git
>you can
>> add a files like:
>> 
>> $ cat ~/.local/share/meson/native/llvm-6.0
>> [binaries]
>> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
>> 
>> and invoke meson with:
>> meson builddir --native-file llvm-6.0
>> 
>> which will configure with the specified llvm-config, and remember the
>> llvm-config used on subsequent reconfigurations. You can override all
>binaries
>> from a native file as well, so if you want to use a specific python3
>or
>> compiler you can do that, and you can load multiple native files in a
>single
>> invocation.
>
>do I understand that correctly as "there is no way to set this on the
>command
>line"? Ie. something like
>meson
>--override-native="llvm-config=/usr/local/lib/llvm-6/bin/llvm-config"
>or something similar? I need to have a file in
>$XDG_DATA_HOME/meson/native? That
>would be really ugly for (automatic) package build environments IMHO,
>especially
>if you want to have reproducible builds. Could these files at least be
>put in
>eg. the debian directory of a source package and then I could pass some
>option
>to meson to look there for these overrides?
>
>Cheers,
>Kai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Gert Wollny]

Am Freitag, den 16.11.2018, 20:04 -0800 schrieb Dylan Baker:
> 
> Is there anything else we're missing in meson to be able to drop
> autotools?

One thing that I notes is that it seems to be impossible to run the
test suite for just one subdirectory because the only way to run the
build is from the binary root directory. With autotools, when I do some
work on a sub-module (like I did with mesa/st) I can just go there and
run make check on the few tests that are there where I actually change
code, with meson/ninja this doesn't seem to be possible and I have to
either run the  full test suite, or run the test executables manually. 

One workaround I found on stack overflow [1] would be to give the
test suites in these subdirectories different names so that one can
then run e.g. 'ninja test.mesa.st' (the example there is using cmake as
a basis to create the build.ninja file though). 

Another think I noted  - and I'm not sure  whether this is a feature or
a bug - is that if CFLAG or CXXFLAGS are set in the environment, then
it seems that the flags that should be added by the buildtype are
ignored (Usually it turns out that -DDEBUG is missing, even though I
selected debug or debugoptimized as build type).

Best, 
Gert

https://stackoverflow.com/questions/28636295/ninja-equivalent-of-makes-
build-from-this-directory-down-feature-with-cmake






> 
> 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] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 17.11.18 05:04:
> Quoting Dylan Baker (2018-09-17 09:44:07)
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is 
>> there
>> anything left that autotools can do that meson cannot (that we actually want 
>> to
>> implement)? And, what is a reasonable time-table to remove the autotools 
>> build?
>> I think we could reasonably remove it as soon as 18.3 if others felt 
>> confident
>> that it would work for them.
>>
>> Dylan
> 
> Okay, time for an update on things and a chance to talk about what else we 
> need.
> 
> Support for llvm-config (and any binary, actually) overriding has landed in
> meson, and will be present in the 0.49.0 release, which is due out December 
> 9th.
> support for ICC has improved a great deal already, and I have a series here:
> https://github.com/mesonbuild/meson/pull/4359 (which may unfortunately not
> land until after 0.49) which should get ICC into pretty good shape on Linux 
> and
> Mac, including actually checking that arguments are understood (which should
> allow us to drop the prefix test from SWR). I have some ideas on how we might
> remove auto options, some of them can already use meson's "feature"
> https://mesonbuild.com/Build-options.html#features option (which should make
> distro packagers happy too), for arch and OS specific options I have some 
> ideas
> and I'll continue following up with those upstream.
> 
> For those interested in llvm-config overriding, with meson out of git you can
> add a files like:
> 
> $ cat ~/.local/share/meson/native/llvm-6.0
> [binaries]
> llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'
> 
> and invoke meson with:
> meson builddir --native-file llvm-6.0
> 
> which will configure with the specified llvm-config, and remember the
> llvm-config used on subsequent reconfigurations. You can override all binaries
> from a native file as well, so if you want to use a specific python3 or
> compiler you can do that, and you can load multiple native files in a single
> invocation.

do I understand that correctly as "there is no way to set this on the command
line"? Ie. something like
  meson --override-native="llvm-config=/usr/local/lib/llvm-6/bin/llvm-config"
or something similar? I need to have a file in $XDG_DATA_HOME/meson/native? That
would be really ugly for (automatic) package build environments IMHO, especially
if you want to have reproducible builds. Could these files at least be put in
eg. the debian directory of a source package and then I could pass some option
to meson to look there for these overrides?

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] Lets talk about autotools

[Dylan Baker]

Quoting Dylan Baker (2018-09-17 09:44:07)
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is 
> there
> anything left that autotools can do that meson cannot (that we actually want 
> to
> implement)? And, what is a reasonable time-table to remove the autotools 
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt confident
> that it would work for them.
> 
> Dylan

Okay, time for an update on things and a chance to talk about what else we need.

Support for llvm-config (and any binary, actually) overriding has landed in
meson, and will be present in the 0.49.0 release, which is due out December 9th.
support for ICC has improved a great deal already, and I have a series here:
https://github.com/mesonbuild/meson/pull/4359 (which may unfortunately not
land until after 0.49) which should get ICC into pretty good shape on Linux and
Mac, including actually checking that arguments are understood (which should
allow us to drop the prefix test from SWR). I have some ideas on how we might
remove auto options, some of them can already use meson's "feature"
https://mesonbuild.com/Build-options.html#features option (which should make
distro packagers happy too), for arch and OS specific options I have some ideas
and I'll continue following up with those upstream.

For those interested in llvm-config overriding, with meson out of git you can
add a files like:

$ cat ~/.local/share/meson/native/llvm-6.0
[binaries]
llvm-conifg = '/usr/local/lib/llvm-6/bin/llvm-config'

and invoke meson with:
meson builddir --native-file llvm-6.0

which will configure with the specified llvm-config, and remember the
llvm-config used on subsequent reconfigurations. You can override all binaries
from a native file as well, so if you want to use a specific python3 or
compiler you can do that, and you can load multiple native files in a single
invocation.

Is there anything else we're missing in meson to be able to drop autotools?

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] Lets talk about autotools

[Matt Turner]

On Fri, Sep 21, 2018 at 11:38 AM Emil Velikov  wrote:
>
> On 20 September 2018 at 19:19, Dylan Baker  wrote:
> > Quoting Eric Engestrom (2018-09-20 07:56:45)
> >> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
> >> > Hi Chuck,
> >> >
> >> > On 18 September 2018 at 16:00, Chuck Atkins  
> >> > wrote:
> >> > > First, I'm fully in support of killing off autotools woo-hoo to that.  
> >> > > And
> >> > > given the substantial investment already put into the meson build that
> >> > > certainly seems like a good direction to go.
> >> > >
> >> > > That being said, the way "auto" is currently implemented leaves quite 
> >> > > a bit
> >> > > to be desired.  One of the nice features of the Autotools build was how
> >> > > auto-enabled options were treated in that the dependencies were 
> >> > > searched for
> >> > > and if they were all found and met then the option would be enabled.  
> >> > > My
> >> > > experience so far with the meson build has shown this not to be the 
> >> > > case and
> >> > > a "configure" with no options has yet to be successful for me.  Many 
> >> > > of the
> >> > > 'auto' options are treated as 'set to true if your platform supports 
> >> > > it'
> >> > > regardless of whether your system has the requisite dependencies 
> >> > > available.
> >> > > For example"
> >> > >
> >> > > The 'gallium-va' option defaults to 'auto' but the implementation ends 
> >> > > up
> >> > > setting the '_va' option to true if the other option conditions are 
> >> > > met,
> >> > > long before libva is searched for.  So then when libva isn't found one 
> >> > > gets
> >> > > an error.
> >> > >
> >> > > if set to auto then missing the libva dependencies should be a 
> >> > > failure, it
> >> > > should just disable the gallium va state tracker
> >> > >
> >> > > The platform options set to 'auto'  has a set of checks to determine 
> >> > > which
> >> > > platforms are enabled as required.  If the system_has_kms_drm check is 
> >> > > true
> >> > > then Wayland is enabled as required.  Later if the check for wayland
> >> > > dependencies fails, an error occurs.
> >> > >
> >> > > If platforms are set to auto then a failure to locate dependencies for 
> >> > > a
> >> > > given platform should disable the platform.
> >> > >
> >> > > I realize these are just two specific examples, each of which can be 
> >> > > readily
> >> > > dealt with in their own specific way so I'm not asking "how to I 
> >> > > address #1
> >> > > and #2?" because I can certainly do that.  These are just two 
> >> > > instances of
> >> > > many though in the way "auto" is dealt with.  My point is really a 
> >> > > broader
> >> > > one that before meson becomes the primary build then the behavior of 
> >> > > "auto"
> >> > > should create a successful configure out of the box without additional
> >> > > options.
> >> > >
> >> > I would like to revive an idea from a few years ago:
> >> > Drop the "auto" all-together.
> >> >
> >> > It adds a _ton_ of complexity while making the build semi-magical/not
> >> > as deterministic.
> >> > IIRC the Gnome people have been actively working for removing such
> >> > autodetection in their packages.
> >> >
> >> > The only downside is that we may need to tweak our scripts _once_ to
> >> > list exactly what we want to build ;-)
> >>
> >> _Once_ for you, because you have everything already set up, but for all
> >> the new users this means that nothing will work out of the box, they'll
> >> need to understand each and every options and figure out what they need
> >> them set to, before they can even start.
> >>
> >> That sounds like a huge step backwards to me :/
> >
> > Especially when one of the explicit goals was to support 4 OS families
> > (Unix-like, windows, mac, haiku). To make that all work out of the box we'd 
> > end
> > up building *nothing* by default.
> >
> As mentioned elsewhere - if you don't know what you're doing (it's
> fine to admit that), simply follow your distribution.
> If you do not trust your distribution ... well. Otherwise - read.

This would generate so many unnecessary support requests. I argued for
the same thing years ago, and I've come to agree that automatically
picking sane defaults is the best solution for everyone, users and
developers alike (for different reasons).
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

On 20 September 2018 at 19:19, Dylan Baker  wrote:
> Quoting Eric Engestrom (2018-09-20 07:56:45)
>> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
>> > Hi Chuck,
>> >
>> > On 18 September 2018 at 16:00, Chuck Atkins  
>> > wrote:
>> > > First, I'm fully in support of killing off autotools woo-hoo to that.  
>> > > And
>> > > given the substantial investment already put into the meson build that
>> > > certainly seems like a good direction to go.
>> > >
>> > > That being said, the way "auto" is currently implemented leaves quite a 
>> > > bit
>> > > to be desired.  One of the nice features of the Autotools build was how
>> > > auto-enabled options were treated in that the dependencies were searched 
>> > > for
>> > > and if they were all found and met then the option would be enabled.  My
>> > > experience so far with the meson build has shown this not to be the case 
>> > > and
>> > > a "configure" with no options has yet to be successful for me.  Many of 
>> > > the
>> > > 'auto' options are treated as 'set to true if your platform supports it'
>> > > regardless of whether your system has the requisite dependencies 
>> > > available.
>> > > For example"
>> > >
>> > > The 'gallium-va' option defaults to 'auto' but the implementation ends up
>> > > setting the '_va' option to true if the other option conditions are met,
>> > > long before libva is searched for.  So then when libva isn't found one 
>> > > gets
>> > > an error.
>> > >
>> > > if set to auto then missing the libva dependencies should be a failure, 
>> > > it
>> > > should just disable the gallium va state tracker
>> > >
>> > > The platform options set to 'auto'  has a set of checks to determine 
>> > > which
>> > > platforms are enabled as required.  If the system_has_kms_drm check is 
>> > > true
>> > > then Wayland is enabled as required.  Later if the check for wayland
>> > > dependencies fails, an error occurs.
>> > >
>> > > If platforms are set to auto then a failure to locate dependencies for a
>> > > given platform should disable the platform.
>> > >
>> > > I realize these are just two specific examples, each of which can be 
>> > > readily
>> > > dealt with in their own specific way so I'm not asking "how to I address 
>> > > #1
>> > > and #2?" because I can certainly do that.  These are just two instances 
>> > > of
>> > > many though in the way "auto" is dealt with.  My point is really a 
>> > > broader
>> > > one that before meson becomes the primary build then the behavior of 
>> > > "auto"
>> > > should create a successful configure out of the box without additional
>> > > options.
>> > >
>> > I would like to revive an idea from a few years ago:
>> > Drop the "auto" all-together.
>> >
>> > It adds a _ton_ of complexity while making the build semi-magical/not
>> > as deterministic.
>> > IIRC the Gnome people have been actively working for removing such
>> > autodetection in their packages.
>> >
>> > The only downside is that we may need to tweak our scripts _once_ to
>> > list exactly what we want to build ;-)
>>
>> _Once_ for you, because you have everything already set up, but for all
>> the new users this means that nothing will work out of the box, they'll
>> need to understand each and every options and figure out what they need
>> them set to, before they can even start.
>>
>> That sounds like a huge step backwards to me :/
>
> Especially when one of the explicit goals was to support 4 OS families
> (Unix-like, windows, mac, haiku). To make that all work out of the box we'd 
> end
> up building *nothing* by default.
>
As mentioned elsewhere - if you don't know what you're doing (it's
fine to admit that), simply follow your distribution.
If you do not trust your distribution ... well. Otherwise - read.

No my call - you'll be fixing corner-cases in meson ;-)

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

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

On Tuesday, 2018-09-18 13:43:25 -0700, Dylan Baker wrote:
> Quoting Kai Wasserbäch (2018-09-18 11:14:19)
> > Dylan Baker wrote on 9/18/18 6:40 PM:
> > > Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> > >> Dylan Baker wrote on 9/18/18 5:35 PM:
> > >>> [...]
> > >>>
> > >>> This is something we've discussed upstream several times. I will freely 
> > >>> admit
> > >>> that llvm-config is a huge pain in the ass to deal with for a ton of 
> > >>> reasons,
> > >>> and since we don't use it at Intel
> > >>
> > >> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is 
> > >> no longer
> > >> the case?
> > > 
> > > Our relationship with the KBL-G is complicated :)
> > 
> > Well, there's also SWR from Intel, which also relies on LLVM...
> > 
> > >>> it hasn't been on the top of my list of
> > >>> things to do, and also because the solution upstream wants is very 
> > >>> non-trival to
> > >>> implement. This has come up already and I am working on it right now.
> > >>
> > >> If upstream support is unreasonable, I'd like to see a similar solution 
> > >> to
> > >> LLVM_CONFIG as it's in autotools today. It must be possible to 
> > >> mangle/override
> > >> the meson variables right? (This might be totally ignorant, because I 
> > >> was able
> > >> to avoid Meson so far and all other build systems I've worked with, have 
> > >> one or
> > >> more options to set variables. Either by having an option in the build 
> > >> files or
> > >> by passing some option into the configure step.)
> > > 
> > > It really isn't, the only way we could really override this today is to 
> > > allow
> > > you to pass a version requirement. One of the guiding ideas of meson is 
> > > that
> > > complicated logic like "how the hell do you make a tool as
> > > broken-by-design-and-implementation as llvm-config work" should be part 
> > > of meson
> > > itself and not in the local build-system. The downside of that is that 
> > > upstream
> > > really wants you to think about how you handle things like overriding a 
> > > specific
> > > binary like llvm-config because it has to live with that decision for a 
> > > long
> > > time.
> > 
> > I'm for the hiding, but why not do it in an easy to change way like the
> > "Find${FOO}.cmake" scripts? As long as you get certain variables populated
> > downstream is happy and an occasional change can be managed, if it should 
> > become
> > necessary. Having everything "in the core" sounds rather inflexible to me. 
> > Or
> > I'm misunderstanding you. Anyway, this isn't really the topic here.
> >
> > >>> The other option you have it to set the $PATH variable, as long as the
> > >>> llvm-config you want returns the highest version things will work as 
> > >>> you expect.
> > >>
> > >> This might do as a workaround, though I'm not too keen on extending 
> > >> $PATH. But
> > >> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
> > >> that
> > >> versions binaries, putting it first into the path could work.
> > > 
> > > meson will cache the llvm-config values, so you should be able to just do
> > > something like:
> > > 
> > > PATH=/path/to/my/llvm meson build-with-my-llvm
> > 
> > Ok. Where's the cache? In the build directory or is this something, that's 
> > kept
> > globally and needs potential clearing? A quick search for this feature 
> > yielded
> > . That makes it sound 
> > like
> > it is global, which I would almost consider broken design. Or is it local 
> > but
> > kept between multiple invocations of meson? That also sounds like a recipe 
> > for
> > disaster, though it would be easier to deal with: just nuke the build 
> > directory.
> 
> It's per build directory, and is kept on subsequent rebuilds. The idea is that
> if you need to reconfigure a build (say meson.build changes) when you do a 
> `git
> pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes 
> the
> rebuild faster. I don't think there is a cache-invalidation method, though 
> that
> would be a nice feature to have.

There is :)
$ meson --internal regenerate

> 
> 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] Lets talk about autotools

[Dylan Baker]

Quoting Mathieu Bridon (2018-09-20 08:34:31)
> On Thu, 2018-09-20 at 15:56 +0100, Eric Engestrom wrote:
> > On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
> > > Hi Chuck,
> > > 
> > > On 18 September 2018 at 16:00, Chuck Atkins <
> > > chuck.atk...@kitware.com> wrote:
> > > > First, I'm fully in support of killing off autotools woo-hoo to
> > > > that.  And
> > > > given the substantial investment already put into the meson build
> > > > that
> > > > certainly seems like a good direction to go.
> > > > 
> > > > That being said, the way "auto" is currently implemented leaves
> > > > quite a bit
> > > > to be desired.  One of the nice features of the Autotools build
> > > > was how
> > > > auto-enabled options were treated in that the dependencies were
> > > > searched for
> > > > and if they were all found and met then the option would be
> > > > enabled.  My
> > > > experience so far with the meson build has shown this not to be
> > > > the case and
> > > > a "configure" with no options has yet to be successful for
> > > > me.  Many of the
> > > > 'auto' options are treated as 'set to true if your platform
> > > > supports it'
> > > > regardless of whether your system has the requisite dependencies
> > > > available.
> > > > For example"
> > > > 
> > > > The 'gallium-va' option defaults to 'auto' but the implementation
> > > > ends up
> > > > setting the '_va' option to true if the other option conditions
> > > > are met,
> > > > long before libva is searched for.  So then when libva isn't
> > > > found one gets
> > > > an error.
> > > > 
> > > > if set to auto then missing the libva dependencies should be a
> > > > failure, it
> > > > should just disable the gallium va state tracker
> > > > 
> > > > The platform options set to 'auto'  has a set of checks to
> > > > determine which
> > > > platforms are enabled as required.  If the system_has_kms_drm
> > > > check is true
> > > > then Wayland is enabled as required.  Later if the check for
> > > > wayland
> > > > dependencies fails, an error occurs.
> > > > 
> > > > If platforms are set to auto then a failure to locate
> > > > dependencies for a
> > > > given platform should disable the platform.
> > > > 
> > > > I realize these are just two specific examples, each of which can
> > > > be readily
> > > > dealt with in their own specific way so I'm not asking "how to I
> > > > address #1
> > > > and #2?" because I can certainly do that.  These are just two
> > > > instances of
> > > > many though in the way "auto" is dealt with.  My point is really
> > > > a broader
> > > > one that before meson becomes the primary build then the behavior
> > > > of "auto"
> > > > should create a successful configure out of the box without
> > > > additional
> > > > options.
> > > > 
> > > 
> > > I would like to revive an idea from a few years ago:
> > > Drop the "auto" all-together.
> > > 
> > > It adds a _ton_ of complexity while making the build semi-
> > > magical/not
> > > as deterministic.
> > > IIRC the Gnome people have been actively working for removing such
> > > autodetection in their packages.
> > > 
> > > The only downside is that we may need to tweak our scripts _once_
> > > to
> > > list exactly what we want to build ;-)
> > 
> > _Once_ for you, because you have everything already set up, but for
> > all
> > the new users this means that nothing will work out of the box,
> > they'll
> > need to understand each and every options and figure out what they
> > need
> > them set to, before they can even start.
> > 
> > That sounds like a huge step backwards to me :/
> 
> Meson has a great feature called… "features".
> 
> The way it works is you have options which can be either enabled,
> disabled or "auto".
> 
> This way, those optional parts of the build can be built automatically
> by default if the required dependencies are present, or skipped if not,
> which seems to be what you want.
> 
> However, meson then has a --auto-features option which allows build
> integrators to get deterministic, reproducible builds by removing the
> automatic enabling/disabling based on dependencies.
> 
> Which seems like it can reconcile what you and Emil want? :)
> 
> More details here:
> 
> http://mesonbuild.com/Build-options.html#features
> 
> As a build integrator myself at the Freedesktop SDK project, I would
> love Mesa to make good use of this.
> 
> We regularly have issues due to this automatic behaviour, because we
> forgot a dependency or added one by mistake.
> 
> 
> -- 
> Mathieu
> 

I'm planning to make use of these, because they're great! Just wanted to wait
until they're not a brand new feature :)

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] Lets talk about autotools

[Dylan Baker]

Quoting Eric Engestrom (2018-09-20 07:56:45)
> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
> > Hi Chuck,
> > 
> > On 18 September 2018 at 16:00, Chuck Atkins  
> > wrote:
> > > First, I'm fully in support of killing off autotools woo-hoo to that.  And
> > > given the substantial investment already put into the meson build that
> > > certainly seems like a good direction to go.
> > >
> > > That being said, the way "auto" is currently implemented leaves quite a 
> > > bit
> > > to be desired.  One of the nice features of the Autotools build was how
> > > auto-enabled options were treated in that the dependencies were searched 
> > > for
> > > and if they were all found and met then the option would be enabled.  My
> > > experience so far with the meson build has shown this not to be the case 
> > > and
> > > a "configure" with no options has yet to be successful for me.  Many of 
> > > the
> > > 'auto' options are treated as 'set to true if your platform supports it'
> > > regardless of whether your system has the requisite dependencies 
> > > available.
> > > For example"
> > >
> > > The 'gallium-va' option defaults to 'auto' but the implementation ends up
> > > setting the '_va' option to true if the other option conditions are met,
> > > long before libva is searched for.  So then when libva isn't found one 
> > > gets
> > > an error.
> > >
> > > if set to auto then missing the libva dependencies should be a failure, it
> > > should just disable the gallium va state tracker
> > >
> > > The platform options set to 'auto'  has a set of checks to determine which
> > > platforms are enabled as required.  If the system_has_kms_drm check is 
> > > true
> > > then Wayland is enabled as required.  Later if the check for wayland
> > > dependencies fails, an error occurs.
> > >
> > > If platforms are set to auto then a failure to locate dependencies for a
> > > given platform should disable the platform.
> > >
> > > I realize these are just two specific examples, each of which can be 
> > > readily
> > > dealt with in their own specific way so I'm not asking "how to I address 
> > > #1
> > > and #2?" because I can certainly do that.  These are just two instances of
> > > many though in the way "auto" is dealt with.  My point is really a broader
> > > one that before meson becomes the primary build then the behavior of 
> > > "auto"
> > > should create a successful configure out of the box without additional
> > > options.
> > >
> > I would like to revive an idea from a few years ago:
> > Drop the "auto" all-together.
> > 
> > It adds a _ton_ of complexity while making the build semi-magical/not
> > as deterministic.
> > IIRC the Gnome people have been actively working for removing such
> > autodetection in their packages.
> > 
> > The only downside is that we may need to tweak our scripts _once_ to
> > list exactly what we want to build ;-)
> 
> _Once_ for you, because you have everything already set up, but for all
> the new users this means that nothing will work out of the box, they'll
> need to understand each and every options and figure out what they need
> them set to, before they can even start.
> 
> That sounds like a huge step backwards to me :/

Especially when one of the explicit goals was to support 4 OS families
(Unix-like, windows, mac, haiku). To make that all work out of the box we'd end
up building *nothing* by default.

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] Lets talk about autotools

[Dylan Baker]

Quoting Emil Velikov (2018-09-20 07:05:07)
> Hi Dylan,
> 
> On 17 September 2018 at 17:44, Dylan Baker  wrote:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is 
> > there
> > anything left that autotools can do that meson cannot (that we actually 
> > want to
> > implement)? And, what is a reasonable time-table to remove the autotools 
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt 
> > confident
> > that it would work for them.
> >
> As pointed out by others - there are some parts where the meson build
> would need an extra bit of polish.
> That said, it's in pretty good shape indeed.
> 
> At the same time, considering the time spent on autotools is more or
> less not nothing, I would suggest being more patient.
> There are Linux distributions and others that still use and/or depend on it.
> 
> As we get to the point of a) keeping autotools is taking too much time
> and/or b) all autotools users have moved to meson sure we can nuke it.

In part this thread is about tracking down the last of the rough edges that
need to be be polished, and to remind some distros, OSes, and developers that
dropping autotools is on the road map, so they should make sure that they're
specific corner of the build is working :)

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] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 9/19/18 6:24 PM:
> Quoting Kai Wasserbäch (2018-09-19 08:04:35)
> [...]
>> In any case, thanks for your replies. I'll see if I can scare up some time 
>> over
>> the weekend and check if I can get Mesa building with meson. Nevertheless I'd
>> like to ask for not making meson mandatory until something like today's
>> LLVM_CONFIG or something equivalent within a released version of meson is 
>> available.
> 
> In case you (or anyone else following this is interested) here's my work in
> progress for getting llvm-config overrides into meson:
> https://github.com/mesonbuild/meson/pull/4216

I left you an inline comment there. In addition to that, I'd like to request
some documentation on this new feature to be included in the PR: what format
does the file have, what can I override, do I need one file per override or
multiple files? Etc.

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] Lets talk about autotools

[Mathieu Bridon]

On Thu, 2018-09-20 at 15:56 +0100, Eric Engestrom wrote:
> On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
> > Hi Chuck,
> > 
> > On 18 September 2018 at 16:00, Chuck Atkins <
> > chuck.atk...@kitware.com> wrote:
> > > First, I'm fully in support of killing off autotools woo-hoo to
> > > that.  And
> > > given the substantial investment already put into the meson build
> > > that
> > > certainly seems like a good direction to go.
> > > 
> > > That being said, the way "auto" is currently implemented leaves
> > > quite a bit
> > > to be desired.  One of the nice features of the Autotools build
> > > was how
> > > auto-enabled options were treated in that the dependencies were
> > > searched for
> > > and if they were all found and met then the option would be
> > > enabled.  My
> > > experience so far with the meson build has shown this not to be
> > > the case and
> > > a "configure" with no options has yet to be successful for
> > > me.  Many of the
> > > 'auto' options are treated as 'set to true if your platform
> > > supports it'
> > > regardless of whether your system has the requisite dependencies
> > > available.
> > > For example"
> > > 
> > > The 'gallium-va' option defaults to 'auto' but the implementation
> > > ends up
> > > setting the '_va' option to true if the other option conditions
> > > are met,
> > > long before libva is searched for.  So then when libva isn't
> > > found one gets
> > > an error.
> > > 
> > > if set to auto then missing the libva dependencies should be a
> > > failure, it
> > > should just disable the gallium va state tracker
> > > 
> > > The platform options set to 'auto'  has a set of checks to
> > > determine which
> > > platforms are enabled as required.  If the system_has_kms_drm
> > > check is true
> > > then Wayland is enabled as required.  Later if the check for
> > > wayland
> > > dependencies fails, an error occurs.
> > > 
> > > If platforms are set to auto then a failure to locate
> > > dependencies for a
> > > given platform should disable the platform.
> > > 
> > > I realize these are just two specific examples, each of which can
> > > be readily
> > > dealt with in their own specific way so I'm not asking "how to I
> > > address #1
> > > and #2?" because I can certainly do that.  These are just two
> > > instances of
> > > many though in the way "auto" is dealt with.  My point is really
> > > a broader
> > > one that before meson becomes the primary build then the behavior
> > > of "auto"
> > > should create a successful configure out of the box without
> > > additional
> > > options.
> > > 
> > 
> > I would like to revive an idea from a few years ago:
> > Drop the "auto" all-together.
> > 
> > It adds a _ton_ of complexity while making the build semi-
> > magical/not
> > as deterministic.
> > IIRC the Gnome people have been actively working for removing such
> > autodetection in their packages.
> > 
> > The only downside is that we may need to tweak our scripts _once_
> > to
> > list exactly what we want to build ;-)
> 
> _Once_ for you, because you have everything already set up, but for
> all
> the new users this means that nothing will work out of the box,
> they'll
> need to understand each and every options and figure out what they
> need
> them set to, before they can even start.
> 
> That sounds like a huge step backwards to me :/

Meson has a great feature called… "features".

The way it works is you have options which can be either enabled,
disabled or "auto".

This way, those optional parts of the build can be built automatically
by default if the required dependencies are present, or skipped if not,
which seems to be what you want.

However, meson then has a --auto-features option which allows build
integrators to get deterministic, reproducible builds by removing the
automatic enabling/disabling based on dependencies.

Which seems like it can reconcile what you and Emil want? :)

More details here:

http://mesonbuild.com/Build-options.html#features

As a build integrator myself at the Freedesktop SDK project, I would
love Mesa to make good use of this.

We regularly have issues due to this automatic behaviour, because we
forgot a dependency or added one by mistake.


-- 
Mathieu

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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

Hi Chuck,

On 20 September 2018 at 16:03, Chuck Atkins  wrote:
> ...
>>
>> Distributions already explicitly specify what they want and most of
>> our autodetection is effectively a bad copy of that.
>
>
> The big difference vs gnome is that *most* gnome packages are consumed by
> users only as system libraries and thus package maintainers are the ones
> build them, so it's not a big deal to have to explicitly configure it how
> you want.  Seldom will you have a miscelaneous user needing to build and use
> thier own version of GNOME libs.  Mesa, on the other hand, has an extensive
> set of users just like that. A substantial portion of mesa's user base are
> graphics developers that have no idea what most of the mesa options are or
> what they do, but just need to have a new mesa build to fix a bug their
> OpenGL code is hitting.  As much as dealing with the "auto" implementation
> sucks, I think it's important that the default out-of-the-box with no
> arguments configuration should be sane and likely to produce something
> useful, even if not optimal.
>
As you've noticed in the thread, experienced devs have script(s) which
adjust the defaults/autodetection to fit their needs.

One thing I've always told people unfamiliar with the process:
Start with the dependencies+toggles that your distribution uses. Then
work up/down.

On Debian that's as trivial as "build-deps" on others - perhaps less no.

That said, I tend to read through the toggles and disable things I do not need.
Guess I'm one of the few ;-)

Either way, autotools is ok on the topic. We'll get to see any missing
corner cases in meson sooner or later.

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

Re: [Mesa-dev] Lets talk about autotools

[Chuck Atkins]

Hi Emil,

I would like to revive an idea from a few years ago:
> Drop the "auto" all-together.
>
> It adds a _ton_ of complexity while making the build semi-magical/not
> as deterministic.
>

I can certainly sympathize here.  I maintain a ton of build infrastructure
for a wide variety of projects and the whole "auto" thing is realy a pain
to deal with from both an implementation and maintenance perspective.



> The only downside is that we may need to tweak our scripts _once_ to
> list exactly what we want to build ;-)
>

That's be nice, but it's simply not reality.  For the past several years
I've neaded to tweak our mesa builds scripts every few releases.  I don't
think that's particularly a problem so I'm not raising it as an issue, just
that the config options are regularly evolving, which is okay, theyre not
static though.



> IIRC the Gnome people have been actively working for removing such
> autodetection in their packages.
>
...

> Distributions already explicitly specify what they want and most of
> our autodetection is effectively a bad copy of that.
>

The big difference vs gnome is that *most* gnome packages are consumed by
users only as system libraries and thus package maintainers are the ones
build them, so it's not a big deal to have to explicitly configure it how
you want.  Seldom will you have a miscelaneous user needing to build and
use thier own version of GNOME libs.  Mesa, on the other hand, has an
extensive set of users just like that. A substantial portion of mesa's user
base are graphics developers that have no idea what most of the mesa
options are or what they do, but just need to have a new mesa build to fix
a bug their OpenGL code is hitting.  As much as dealing with the "auto"
implementation sucks, I think it's important that the default
out-of-the-box with no arguments configuration should be sane and likely to
produce something useful, even if not optimal.

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

Re: [Mesa-dev] Lets talk about autotools

[Daniel Stone]

Hi Emil,

On Thu, 20 Sep 2018 at 15:36, Emil Velikov  wrote:
> Mildly related: when using meson, make that you have patchelf or similar tool.
> It nukes the RPATH, removing the need to relink the binaries [as it
> happens on make install].
>
> Perhaps meson should error out when that's missing?

There is no dependency on external tools; it is implemented within
Meson itself, so no need to error out.

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

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

On Thursday, 2018-09-20 15:28:09 +0100, Emil Velikov wrote:
> Hi Chuck,
> 
> On 18 September 2018 at 16:00, Chuck Atkins  wrote:
> > First, I'm fully in support of killing off autotools woo-hoo to that.  And
> > given the substantial investment already put into the meson build that
> > certainly seems like a good direction to go.
> >
> > That being said, the way "auto" is currently implemented leaves quite a bit
> > to be desired.  One of the nice features of the Autotools build was how
> > auto-enabled options were treated in that the dependencies were searched for
> > and if they were all found and met then the option would be enabled.  My
> > experience so far with the meson build has shown this not to be the case and
> > a "configure" with no options has yet to be successful for me.  Many of the
> > 'auto' options are treated as 'set to true if your platform supports it'
> > regardless of whether your system has the requisite dependencies available.
> > For example"
> >
> > The 'gallium-va' option defaults to 'auto' but the implementation ends up
> > setting the '_va' option to true if the other option conditions are met,
> > long before libva is searched for.  So then when libva isn't found one gets
> > an error.
> >
> > if set to auto then missing the libva dependencies should be a failure, it
> > should just disable the gallium va state tracker
> >
> > The platform options set to 'auto'  has a set of checks to determine which
> > platforms are enabled as required.  If the system_has_kms_drm check is true
> > then Wayland is enabled as required.  Later if the check for wayland
> > dependencies fails, an error occurs.
> >
> > If platforms are set to auto then a failure to locate dependencies for a
> > given platform should disable the platform.
> >
> > I realize these are just two specific examples, each of which can be readily
> > dealt with in their own specific way so I'm not asking "how to I address #1
> > and #2?" because I can certainly do that.  These are just two instances of
> > many though in the way "auto" is dealt with.  My point is really a broader
> > one that before meson becomes the primary build then the behavior of "auto"
> > should create a successful configure out of the box without additional
> > options.
> >
> I would like to revive an idea from a few years ago:
> Drop the "auto" all-together.
> 
> It adds a _ton_ of complexity while making the build semi-magical/not
> as deterministic.
> IIRC the Gnome people have been actively working for removing such
> autodetection in their packages.
> 
> The only downside is that we may need to tweak our scripts _once_ to
> list exactly what we want to build ;-)

_Once_ for you, because you have everything already set up, but for all
the new users this means that nothing will work out of the box, they'll
need to understand each and every options and figure out what they need
them set to, before they can even start.

That sounds like a huge step backwards to me :/

> Distributions already explicitly specify what they want and most of
> our autodetection is effectively a bad copy of that.
> 
> HTH
> Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

On 18 September 2018 at 20:16, Gert Wollny  wrote:
> Am Montag, den 17.09.2018, 17:07 -0400 schrieb Marek Olšák:
>> I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
> +1
>
> With autotools I can use an uninstalled but compiled version of meson
> (e.g. for testing) by pointing LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> to the $BUILDDIR/lib and $BUILDDIR/lib/gallium respectively.  With
> meson it seems one always needs to run "ninja install" to get the
> actual drivers and libraries somewhere.
>
> It would be nice if meson would act like autotools in that regard by
> creating the drivers and libraries in specific directories (also as a
> configure option if there is concern about compilation speed).
>
This, please.

When we proposed nuking that from autotools there was some _very_
heated discussion.
It wasn't an issue about relinking, but compat with workflows for
dozens (if not a hundred) of developers.

Mildly related: when using meson, make that you have patchelf or similar tool.
It nukes the RPATH, removing the need to relink the binaries [as it
happens on make install].

Perhaps meson should error out when that's missing?

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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

Hi Chuck,

On 18 September 2018 at 16:00, Chuck Atkins  wrote:
> First, I'm fully in support of killing off autotools woo-hoo to that.  And
> given the substantial investment already put into the meson build that
> certainly seems like a good direction to go.
>
> That being said, the way "auto" is currently implemented leaves quite a bit
> to be desired.  One of the nice features of the Autotools build was how
> auto-enabled options were treated in that the dependencies were searched for
> and if they were all found and met then the option would be enabled.  My
> experience so far with the meson build has shown this not to be the case and
> a "configure" with no options has yet to be successful for me.  Many of the
> 'auto' options are treated as 'set to true if your platform supports it'
> regardless of whether your system has the requisite dependencies available.
> For example"
>
> The 'gallium-va' option defaults to 'auto' but the implementation ends up
> setting the '_va' option to true if the other option conditions are met,
> long before libva is searched for.  So then when libva isn't found one gets
> an error.
>
> if set to auto then missing the libva dependencies should be a failure, it
> should just disable the gallium va state tracker
>
> The platform options set to 'auto'  has a set of checks to determine which
> platforms are enabled as required.  If the system_has_kms_drm check is true
> then Wayland is enabled as required.  Later if the check for wayland
> dependencies fails, an error occurs.
>
> If platforms are set to auto then a failure to locate dependencies for a
> given platform should disable the platform.
>
> I realize these are just two specific examples, each of which can be readily
> dealt with in their own specific way so I'm not asking "how to I address #1
> and #2?" because I can certainly do that.  These are just two instances of
> many though in the way "auto" is dealt with.  My point is really a broader
> one that before meson becomes the primary build then the behavior of "auto"
> should create a successful configure out of the box without additional
> options.
>
I would like to revive an idea from a few years ago:
Drop the "auto" all-together.

It adds a _ton_ of complexity while making the build semi-magical/not
as deterministic.
IIRC the Gnome people have been actively working for removing such
autodetection in their packages.

The only downside is that we may need to tweak our scripts _once_ to
list exactly what we want to build ;-)
Distributions already explicitly specify what they want and most of
our autodetection is effectively a bad copy of that.

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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

On 18 September 2018 at 15:43, Kai Wasserbäch
 wrote:
> Hey,
> Dylan Baker wrote on 9/17/18 6:44 PM:
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is 
>> there
>> anything left that autotools can do that meson cannot (that we actually want 
>> to
>> implement)? And, what is a reasonable time-table to remove the autotools 
>> build?
>> I think we could reasonably remove it as soon as 18.3 if others felt 
>> confident
>> that it would work for them.
>
> How do I set a specific llvm-config name to look for? I have build 
> environments
> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
> could convince each build system with LLVM_CONFIG or similar means to choose a
> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
>
> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
> particular
> llvm-config-${VERSION} to llvm-config in $PATH
> ().
> But I think this should be fixed properly before making meson mandatory. Other
> modern build systems like CMake react to something like -DLLVM_DIR during
> configure (see
> ) and Mesa's
> stable build systems use LLVM_CONFIG, if set.
>
Dylan, please CC/point us to the cleaner llvm-config solution once
you've got the chance.
I've nuked a ton of LLVM hacks recently (locally) and having LLVM
almost hack-free would be amazing.

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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

On 18 September 2018 at 01:49, Marek Olšák  wrote:
> One missing feature is --with-sha1=. libcrypto has an unstable ABI and
> Steam uses it. For Mesa to work with Steam, libnettle has/had to be
> used instead.
>

--with-sha1 was nuked back in Jan 2017 with commit
d1efa09d342bff3e5def2978a0bef748d74f9c82

Amongst the problems pointed out, there was some ~150loc build system
chaos, ~250loc compat wrappers.
While the sha1 implementation itself is ~200loc

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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

On 17 September 2018 at 22:23, Marek Olšák  wrote:
> What's the rationale for enabling glx-tls by default without the
> option to change it?
>
Toggling the option changes the ABI produced. Esp. when you consider
earlier Xservers where libglx.so was a major user.
The early Intel QA team had _ton_ of issues with that.

From a perf. POV it does help, plus the Nvidia blob has used the
same(?) TLS magic as well.
Some platforms (some BSDs, Haiku, Solaris + deriv.) do not quite
support it yet, and I've poking those people to fixup their C runtime
library.

Feel free to lend a hand and poke some more ;-)

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

Re: [Mesa-dev] Lets talk about autotools

[Emil Velikov]

Hi Dylan,

On 17 September 2018 at 17:44, Dylan Baker  wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is 
> there
> anything left that autotools can do that meson cannot (that we actually want 
> to
> implement)? And, what is a reasonable time-table to remove the autotools 
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt confident
> that it would work for them.
>
As pointed out by others - there are some parts where the meson build
would need an extra bit of polish.
That said, it's in pretty good shape indeed.

At the same time, considering the time spent on autotools is more or
less not nothing, I would suggest being more patient.
There are Linux distributions and others that still use and/or depend on it.

As we get to the point of a) keeping autotools is taking too much time
and/or b) all autotools users have moved to meson sure we can nuke it.

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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-09-19 08:04:35)
> Hey Dylan,
> Dylan Baker wrote on 9/18/18 10:43 PM:
> > Quoting Kai Wasserbäch (2018-09-18 11:14:19)
> >> Dylan Baker wrote on 9/18/18 6:40 PM:
> >>> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
>  Dylan Baker wrote on 9/18/18 5:35 PM:
> > [...]
> >
> > The other option you have it to set the $PATH variable, as long as the
> > llvm-config you want returns the highest version things will work as 
> > you expect.
> 
>  This might do as a workaround, though I'm not too keen on extending 
>  $PATH. But
>  as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
>  that
>  versions binaries, putting it first into the path could work.
> >>>
> >>> meson will cache the llvm-config values, so you should be able to just do
> >>> something like:
> >>>
> >>> PATH=/path/to/my/llvm meson build-with-my-llvm
> >>
> >> Ok. Where's the cache? In the build directory or is this something, that's 
> >> kept
> >> globally and needs potential clearing? A quick search for this feature 
> >> yielded
> >> . That makes it 
> >> sound like
> >> it is global, which I would almost consider broken design. Or is it local 
> >> but
> >> kept between multiple invocations of meson? That also sounds like a recipe 
> >> for
> >> disaster, though it would be easier to deal with: just nuke the build 
> >> directory.
> > 
> > It's per build directory, and is kept on subsequent rebuilds. The idea is 
> > that
> > if you need to reconfigure a build (say meson.build changes) when you do a 
> > `git
> > pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it 
> > makes the
> > rebuild faster. I don't think there is a cache-invalidation method, though 
> > that
> > would be a nice feature to have.
> 
> I think I can work with that: one build-directory per build and nuke it 
> afterwards.
> 
> As a side note: to me this sounds like a mis-feature or at least something 
> that
> you should have to turn on explicitly. I'd rather pay a little time penalty
> (which isn't too much these days, given how fast SSDs and systems in general
> have become), than using some stale value. Especially since it sounds like 
> meson
> is caching the values of environment variables as well? Which would make usage
> of MESA_GIT_SHA1_OVERRIDE after some changes awkward (which value is used and 
> why).

meson only caches environment variables it cares about, CFLAGS, CC,
PKG_CONFIG_PATH.

> In any case, thanks for your replies. I'll see if I can scare up some time 
> over
> the weekend and check if I can get Mesa building with meson. Nevertheless I'd
> like to ask for not making meson mandatory until something like today's
> LLVM_CONFIG or something equivalent within a released version of meson is 
> available.

In case you (or anyone else following this is interested) here's my work in
progress for getting llvm-config overrides into meson:
https://github.com/mesonbuild/meson/pull/4216

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] Lets talk about autotools

[Dylan Baker]

Quoting Ilia Mirkin (2018-09-17 17:56:15)
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker  wrote:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is 
> > there
> > anything left that autotools can do that meson cannot (that we actually 
> > want to
> > implement)? And, what is a reasonable time-table to remove the autotools 
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt 
> > confident
> > that it would work for them.
> 
> I remember there was a particularly egregious failure mode for meson
> where running "meson configure help" would fail if any of the
> dependencies were missing for whatever the default was. Has that been
> resolved?

Do you mean `meson configure --help`? That doesn't run any of the options from
the local build, it just shows the meson global options.

`meson configure $builddir` does run the config script, at least with 0.47.2
this works fine even with a missing dependency (I set gallium-omx to tizonia and
it works).

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] Lets talk about autotools

[Ian Romanick]

On 09/18/2018 10:38 AM, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-09-18 09:59:22)
>> On Tuesday, 2018-09-18 09:35:20 -0700, Dylan Baker wrote:
>>> Quoting Eric Engestrom (2018-09-18 09:00:49)
 On Tuesday, 2018-09-18 08:24:52 -0700, Dylan Baker wrote:
> Quoting Kenneth Graunke (2018-09-18 01:40:48)
>> On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
>>> Quoting Marek Ol\u0161ák (2018-09-17 15:14:11)
 How do I build 32-bit Mesa with meson?

 Thanks,
 Marek

>>>
>>> Some people get away with just adding CFLAGs=-m32, but using a cross 
>>> file and
>>> doing a cross build is a better way, and is basically required if you 
>>> want llvm.
>>> Here's mine: https://gitlab.freedesktop.org/snippets/504
>>>
>>> Dylan
>>
>> I've attached mine, I then do:
>>
>> meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
>> --prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
>> -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
>> build/32
>>
>> Other than the addition of --cross-file, it's just like any other build.
>
> If you put your cross file in ~/.local/share/meson/cross then you could 
> just do
>
> meson --cross-file=meson-32-cross --buildtype=release 
> --prefix=$PWD/build/32/install -Ddri-drivers=i965 -Dvulkan-drivers=intel 
> -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32
>
> I think Eric Engstrom also landed is if-debug patches, so ndebug is by 
> default
> only enabled for debug and debugoptimized builds now. I think.

 Other way around: b_ndebug is false by default and can be manually set
 to true, or to if-release in which case it is true if buildtype=release,
 but still false for debugoptimised, debug, minsize and plain unless
 specified.
>>>
>>> ndebug makes my head hurt. I really wish that meson would have called the 
>>> option
>>> "b_assert" so it could be true for asserts on and false for asserts off. You
>>> know what, I'm going to go propose that right now.
>>
>> I know, and I kind of agree, but it's not gonna fly, because what meson
>> controls with this option is NDEBUG which is a (de facto?) standard, and
>> that flag can control more than just asserts.
> 
> In C/C++ that's true. What about in Rust and D (for example)? It really feels
> like carrying legacy cruft around.

You're working on this project and complaining about cruft?  Lol



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] Lets talk about autotools

[Ian Romanick]

On 09/18/2018 12:16 PM, Gert Wollny wrote:
> Am Montag, den 17.09.2018, 17:07 -0400 schrieb Marek Olšák:
>> I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
> +1 
> 
> With autotools I can use an uninstalled but compiled version of meson
> (e.g. for testing) by pointing LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> to the $BUILDDIR/lib and $BUILDDIR/lib/gallium respectively.  With
> meson it seems one always needs to run "ninja install" to get the
> actual drivers and libraries somewhere.

I do the same thing.  The way I worked around this was to set the
install dir to the build dir.  My build script has something like:

DESTDIR=$PWD/$DIR ninja-build -C $DIR install

> It would be nice if meson would act like autotools in that regard by
> creating the drivers and libraries in specific directories (also as a
> configure option if there is concern about compilation speed). 
> 
> Thanks,
> Gert 
> 
>>
>> Thanks,
>> Marek
>>
>> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker 
>> wrote:
>>> I feel like for !windows meson is in good enough shape at this
>>> point that we
>>> can start having the discussion about deleting the autotools build.
>>> So, is there
>>> anything left that autotools can do that meson cannot (that we
>>> actually want to
>>> implement)? And, what is a reasonable time-table to remove the
>>> autotools build?
>>> I think we could reasonably remove it as soon as 18.3 if others
>>> felt confident
>>> that it would work for them.
>>>
>>> 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
> 
> ___
> 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] Lets talk about autotools

[Kai Wasserbäch]

Hey Dylan,
Dylan Baker wrote on 9/18/18 10:43 PM:
> Quoting Kai Wasserbäch (2018-09-18 11:14:19)
>> Dylan Baker wrote on 9/18/18 6:40 PM:
>>> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
 Dylan Baker wrote on 9/18/18 5:35 PM:
> [...]
>
> The other option you have it to set the $PATH variable, as long as the
> llvm-config you want returns the highest version things will work as you 
> expect.

 This might do as a workaround, though I'm not too keen on extending $PATH. 
 But
 as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
 that
 versions binaries, putting it first into the path could work.
>>>
>>> meson will cache the llvm-config values, so you should be able to just do
>>> something like:
>>>
>>> PATH=/path/to/my/llvm meson build-with-my-llvm
>>
>> Ok. Where's the cache? In the build directory or is this something, that's 
>> kept
>> globally and needs potential clearing? A quick search for this feature 
>> yielded
>> . That makes it sound 
>> like
>> it is global, which I would almost consider broken design. Or is it local but
>> kept between multiple invocations of meson? That also sounds like a recipe 
>> for
>> disaster, though it would be easier to deal with: just nuke the build 
>> directory.
> 
> It's per build directory, and is kept on subsequent rebuilds. The idea is that
> if you need to reconfigure a build (say meson.build changes) when you do a 
> `git
> pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes 
> the
> rebuild faster. I don't think there is a cache-invalidation method, though 
> that
> would be a nice feature to have.

I think I can work with that: one build-directory per build and nuke it 
afterwards.

As a side note: to me this sounds like a mis-feature or at least something that
you should have to turn on explicitly. I'd rather pay a little time penalty
(which isn't too much these days, given how fast SSDs and systems in general
have become), than using some stale value. Especially since it sounds like meson
is caching the values of environment variables as well? Which would make usage
of MESA_GIT_SHA1_OVERRIDE after some changes awkward (which value is used and 
why).

In any case, thanks for your replies. I'll see if I can scare up some time over
the weekend and check if I can get Mesa building with meson. Nevertheless I'd
like to ask for not making meson mandatory until something like today's
LLVM_CONFIG or something equivalent within a released version of meson is 
available.

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] Lets talk about autotools

[Dylan Baker]

Quoting Adam Jackson (2018-09-18 13:57:18)
> On Tue, 2018-09-18 at 13:50 -0700, Dylan Baker wrote:
> 
> > > It would be nice if meson would act like autotools in that regard by
> > > creating the drivers and libraries in specific directories (also as a
> > > configure option if there is concern about compilation speed). 
> > 
> > This is impossible by design. Meson is very specific that its internal 
> > directory
> > layout is an implementation detail. On top of that, there are two different
> > backends, a VS and ninja backend, which have slightly different layouts.
> 
> I'm not entirely sure that's true? mesa/build-lib/meson.build could
> have all the final link targets, and their results would show up in
> mesa/${builddir}/build-lib. It'd mean mirroring all the "do I build
> this target or not" logic in that meson.build, and you'd descend into
> that directory last from the top-level mesa/meson.build, but...

Unless you pass --layout=flat (I don't think any released versions have this 
yet).
Or upstream decides it wants to change something. It's playing with fire either
way, since upstream is very clear that you should not rely on it.

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] Lets talk about autotools

[Adam Jackson]

On Tue, 2018-09-18 at 13:50 -0700, Dylan Baker wrote:

> > It would be nice if meson would act like autotools in that regard by
> > creating the drivers and libraries in specific directories (also as a
> > configure option if there is concern about compilation speed). 
> 
> This is impossible by design. Meson is very specific that its internal 
> directory
> layout is an implementation detail. On top of that, there are two different
> backends, a VS and ninja backend, which have slightly different layouts.

I'm not entirely sure that's true? mesa/build-lib/meson.build could
have all the final link targets, and their results would show up in
mesa/${builddir}/build-lib. It'd mean mirroring all the "do I build
this target or not" logic in that meson.build, and you'd descend into
that directory last from the top-level mesa/meson.build, but...

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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Gert Wollny (2018-09-18 12:16:01)
> Am Montag, den 17.09.2018, 17:07 -0400 schrieb Marek Ol\u0161ák:
> > I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
> +1 
> 
> With autotools I can use an uninstalled but compiled version of meson
> (e.g. for testing) by pointing LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
> to the $BUILDDIR/lib and $BUILDDIR/lib/gallium respectively.  With
> meson it seems one always needs to run "ninja install" to get the
> actual drivers and libraries somewhere.

ninja installs are very fast and cheap, unlike autotools. Most of us using meson
already just do `meson builddir --prefix=$PWD/builddir; ninja -C builddir
install`, then you can point LD_LIBRARY_PATH and LIBGL_DRIVERS_DIR at
$PWD/builddir/lib and $PWD/builddir/lib/dri.

> It would be nice if meson would act like autotools in that regard by
> creating the drivers and libraries in specific directories (also as a
> configure option if there is concern about compilation speed). 

This is impossible by design. Meson is very specific that its internal directory
layout is an implementation detail. On top of that, there are two different
backends, a VS and ninja backend, which have slightly different layouts.

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] Lets talk about autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-09-18 11:14:19)
> Dylan Baker wrote on 9/18/18 6:40 PM:
> > Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> >> Dylan Baker wrote on 9/18/18 5:35 PM:
> >>> [...]
> >>>
> >>> This is something we've discussed upstream several times. I will freely 
> >>> admit
> >>> that llvm-config is a huge pain in the ass to deal with for a ton of 
> >>> reasons,
> >>> and since we don't use it at Intel
> >>
> >> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
> >> longer
> >> the case?
> > 
> > Our relationship with the KBL-G is complicated :)
> 
> Well, there's also SWR from Intel, which also relies on LLVM...
> 
> >>> it hasn't been on the top of my list of
> >>> things to do, and also because the solution upstream wants is very 
> >>> non-trival to
> >>> implement. This has come up already and I am working on it right now.
> >>
> >> If upstream support is unreasonable, I'd like to see a similar solution to
> >> LLVM_CONFIG as it's in autotools today. It must be possible to 
> >> mangle/override
> >> the meson variables right? (This might be totally ignorant, because I was 
> >> able
> >> to avoid Meson so far and all other build systems I've worked with, have 
> >> one or
> >> more options to set variables. Either by having an option in the build 
> >> files or
> >> by passing some option into the configure step.)
> > 
> > It really isn't, the only way we could really override this today is to 
> > allow
> > you to pass a version requirement. One of the guiding ideas of meson is that
> > complicated logic like "how the hell do you make a tool as
> > broken-by-design-and-implementation as llvm-config work" should be part of 
> > meson
> > itself and not in the local build-system. The downside of that is that 
> > upstream
> > really wants you to think about how you handle things like overriding a 
> > specific
> > binary like llvm-config because it has to live with that decision for a long
> > time.
> 
> I'm for the hiding, but why not do it in an easy to change way like the
> "Find${FOO}.cmake" scripts? As long as you get certain variables populated
> downstream is happy and an occasional change can be managed, if it should 
> become
> necessary. Having everything "in the core" sounds rather inflexible to me. Or
> I'm misunderstanding you. Anyway, this isn't really the topic here.
>
> >>> The other option you have it to set the $PATH variable, as long as the
> >>> llvm-config you want returns the highest version things will work as you 
> >>> expect.
> >>
> >> This might do as a workaround, though I'm not too keen on extending $PATH. 
> >> But
> >> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain 
> >> that
> >> versions binaries, putting it first into the path could work.
> > 
> > meson will cache the llvm-config values, so you should be able to just do
> > something like:
> > 
> > PATH=/path/to/my/llvm meson build-with-my-llvm
> 
> Ok. Where's the cache? In the build directory or is this something, that's 
> kept
> globally and needs potential clearing? A quick search for this feature yielded
> . That makes it sound 
> like
> it is global, which I would almost consider broken design. Or is it local but
> kept between multiple invocations of meson? That also sounds like a recipe for
> disaster, though it would be easier to deal with: just nuke the build 
> directory.

It's per build directory, and is kept on subsequent rebuilds. The idea is that
if you need to reconfigure a build (say meson.build changes) when you do a `git
pull` that pkg-config, llvm-config, and fiends don't get reinvoked, it makes the
rebuild faster. I don't think there is a cache-invalidation method, though that
would be a nice feature to have.

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] Lets talk about autotools

[Gert Wollny]

Am Montag, den 17.09.2018, 17:07 -0400 schrieb Marek Olšák:
> I don't see radeonsi_dri.so. How/where is radeonsi_dri.so created?
+1 

With autotools I can use an uninstalled but compiled version of meson
(e.g. for testing) by pointing LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH
to the $BUILDDIR/lib and $BUILDDIR/lib/gallium respectively.  With
meson it seems one always needs to run "ninja install" to get the
actual drivers and libraries somewhere.

It would be nice if meson would act like autotools in that regard by
creating the drivers and libraries in specific directories (also as a
configure option if there is concern about compilation speed). 

Thanks,
Gert 

> 
> Thanks,
> Marek
> 
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker 
> wrote:
> > I feel like for !windows meson is in good enough shape at this
> > point that we
> > can start having the discussion about deleting the autotools build.
> > So, is there
> > anything left that autotools can do that meson cannot (that we
> > actually want to
> > implement)? And, what is a reasonable time-table to remove the
> > autotools build?
> > I think we could reasonably remove it as soon as 18.3 if others
> > felt confident
> > that it would work for them.
> > 
> > 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

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

Re: [Mesa-dev] Lets talk about autotools

[Kai Wasserbäch]

Dylan Baker wrote on 9/18/18 6:40 PM:
> Quoting Kai Wasserbäch (2018-09-18 08:56:30)
>> Dylan Baker wrote on 9/18/18 5:35 PM:
>>> [...]
>>>
>>> This is something we've discussed upstream several times. I will freely 
>>> admit
>>> that llvm-config is a huge pain in the ass to deal with for a ton of 
>>> reasons,
>>> and since we don't use it at Intel
>>
>> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
>> longer
>> the case?
> 
> Our relationship with the KBL-G is complicated :)

Well, there's also SWR from Intel, which also relies on LLVM...

>>> it hasn't been on the top of my list of
>>> things to do, and also because the solution upstream wants is very 
>>> non-trival to
>>> implement. This has come up already and I am working on it right now.
>>
>> If upstream support is unreasonable, I'd like to see a similar solution to
>> LLVM_CONFIG as it's in autotools today. It must be possible to 
>> mangle/override
>> the meson variables right? (This might be totally ignorant, because I was 
>> able
>> to avoid Meson so far and all other build systems I've worked with, have one 
>> or
>> more options to set variables. Either by having an option in the build files 
>> or
>> by passing some option into the configure step.)
> 
> It really isn't, the only way we could really override this today is to allow
> you to pass a version requirement. One of the guiding ideas of meson is that
> complicated logic like "how the hell do you make a tool as
> broken-by-design-and-implementation as llvm-config work" should be part of 
> meson
> itself and not in the local build-system. The downside of that is that 
> upstream
> really wants you to think about how you handle things like overriding a 
> specific
> binary like llvm-config because it has to live with that decision for a long
> time.

I'm for the hiding, but why not do it in an easy to change way like the
"Find${FOO}.cmake" scripts? As long as you get certain variables populated
downstream is happy and an occasional change can be managed, if it should become
necessary. Having everything "in the core" sounds rather inflexible to me. Or
I'm misunderstanding you. Anyway, this isn't really the topic here.

>>> The other option you have it to set the $PATH variable, as long as the
>>> llvm-config you want returns the highest version things will work as you 
>>> expect.
>>
>> This might do as a workaround, though I'm not too keen on extending $PATH. 
>> But
>> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain that
>> versions binaries, putting it first into the path could work.
> 
> meson will cache the llvm-config values, so you should be able to just do
> something like:
> 
> PATH=/path/to/my/llvm meson build-with-my-llvm

Ok. Where's the cache? In the build directory or is this something, that's kept
globally and needs potential clearing? A quick search for this feature yielded
. That makes it sound like
it is global, which I would almost consider broken design. Or is it local but
kept between multiple invocations of meson? That also sounds like a recipe for
disaster, though it would be easier to deal with: just nuke the build directory.

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] Lets talk about autotools

[Dylan Baker]

Quoting Eric Engestrom (2018-09-18 09:59:22)
> On Tuesday, 2018-09-18 09:35:20 -0700, Dylan Baker wrote:
> > Quoting Eric Engestrom (2018-09-18 09:00:49)
> > > On Tuesday, 2018-09-18 08:24:52 -0700, Dylan Baker wrote:
> > > > Quoting Kenneth Graunke (2018-09-18 01:40:48)
> > > > > On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> > > > > > Quoting Marek Ol\u0161ák (2018-09-17 15:14:11)
> > > > > > > How do I build 32-bit Mesa with meson?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Marek
> > > > > > > 
> > > > > > 
> > > > > > Some people get away with just adding CFLAGs=-m32, but using a 
> > > > > > cross file and
> > > > > > doing a cross build is a better way, and is basically required if 
> > > > > > you want llvm.
> > > > > > Here's mine: https://gitlab.freedesktop.org/snippets/504
> > > > > > 
> > > > > > Dylan
> > > > > 
> > > > > I've attached mine, I then do:
> > > > > 
> > > > > meson --cross-file=/home/kwg/.local/meson-32-cross 
> > > > > --buildtype=release --prefix=/home/kwg/Projects/mesa/build/32/install 
> > > > > -Ddri-drivers=i965 -Dvulkan-drivers=intel -Dgallium-drivers= 
> > > > > -Db_ndebug=true -Dglvnd=true build/32
> > > > > 
> > > > > Other than the addition of --cross-file, it's just like any other 
> > > > > build.
> > > > 
> > > > If you put your cross file in ~/.local/share/meson/cross then you could 
> > > > just do
> > > > 
> > > > meson --cross-file=meson-32-cross --buildtype=release 
> > > > --prefix=$PWD/build/32/install -Ddri-drivers=i965 
> > > > -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
> > > > build/32
> > > > 
> > > > I think Eric Engstrom also landed is if-debug patches, so ndebug is by 
> > > > default
> > > > only enabled for debug and debugoptimized builds now. I think.
> > > 
> > > Other way around: b_ndebug is false by default and can be manually set
> > > to true, or to if-release in which case it is true if buildtype=release,
> > > but still false for debugoptimised, debug, minsize and plain unless
> > > specified.
> > 
> > ndebug makes my head hurt. I really wish that meson would have called the 
> > option
> > "b_assert" so it could be true for asserts on and false for asserts off. You
> > know what, I'm going to go propose that right now.
> 
> I know, and I kind of agree, but it's not gonna fly, because what meson
> controls with this option is NDEBUG which is a (de facto?) standard, and
> that flag can control more than just asserts.

In C/C++ that's true. What about in Rust and D (for example)? It really feels
like carrying legacy cruft around.


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

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

On Tuesday, 2018-09-18 09:35:20 -0700, Dylan Baker wrote:
> Quoting Eric Engestrom (2018-09-18 09:00:49)
> > On Tuesday, 2018-09-18 08:24:52 -0700, Dylan Baker wrote:
> > > Quoting Kenneth Graunke (2018-09-18 01:40:48)
> > > > On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> > > > > Quoting Marek Ol\u0161ák (2018-09-17 15:14:11)
> > > > > > How do I build 32-bit Mesa with meson?
> > > > > > 
> > > > > > Thanks,
> > > > > > Marek
> > > > > > 
> > > > > 
> > > > > Some people get away with just adding CFLAGs=-m32, but using a cross 
> > > > > file and
> > > > > doing a cross build is a better way, and is basically required if you 
> > > > > want llvm.
> > > > > Here's mine: https://gitlab.freedesktop.org/snippets/504
> > > > > 
> > > > > Dylan
> > > > 
> > > > I've attached mine, I then do:
> > > > 
> > > > meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
> > > > --prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
> > > > -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
> > > > build/32
> > > > 
> > > > Other than the addition of --cross-file, it's just like any other build.
> > > 
> > > If you put your cross file in ~/.local/share/meson/cross then you could 
> > > just do
> > > 
> > > meson --cross-file=meson-32-cross --buildtype=release 
> > > --prefix=$PWD/build/32/install -Ddri-drivers=i965 -Dvulkan-drivers=intel 
> > > -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32
> > > 
> > > I think Eric Engstrom also landed is if-debug patches, so ndebug is by 
> > > default
> > > only enabled for debug and debugoptimized builds now. I think.
> > 
> > Other way around: b_ndebug is false by default and can be manually set
> > to true, or to if-release in which case it is true if buildtype=release,
> > but still false for debugoptimised, debug, minsize and plain unless
> > specified.
> 
> ndebug makes my head hurt. I really wish that meson would have called the 
> option
> "b_assert" so it could be true for asserts on and false for asserts off. You
> know what, I'm going to go propose that right now.

I know, and I kind of agree, but it's not gonna fly, because what meson
controls with this option is NDEBUG which is a (de facto?) standard, and
that flag can control more than just asserts.

You're about 30 years too late to try to change this ¯\_(ツ)_/¯

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

Re: [Mesa-dev] Lets talk about autotools

[Dylan Baker]

Quoting Eric Engestrom (2018-09-18 09:00:49)
> On Tuesday, 2018-09-18 08:24:52 -0700, Dylan Baker wrote:
> > Quoting Kenneth Graunke (2018-09-18 01:40:48)
> > > On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> > > > Quoting Marek Ol\u0161ák (2018-09-17 15:14:11)
> > > > > How do I build 32-bit Mesa with meson?
> > > > > 
> > > > > Thanks,
> > > > > Marek
> > > > > 
> > > > 
> > > > Some people get away with just adding CFLAGs=-m32, but using a cross 
> > > > file and
> > > > doing a cross build is a better way, and is basically required if you 
> > > > want llvm.
> > > > Here's mine: https://gitlab.freedesktop.org/snippets/504
> > > > 
> > > > Dylan
> > > 
> > > I've attached mine, I then do:
> > > 
> > > meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
> > > --prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
> > > -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
> > > build/32
> > > 
> > > Other than the addition of --cross-file, it's just like any other build.
> > 
> > If you put your cross file in ~/.local/share/meson/cross then you could 
> > just do
> > 
> > meson --cross-file=meson-32-cross --buildtype=release 
> > --prefix=$PWD/build/32/install -Ddri-drivers=i965 -Dvulkan-drivers=intel 
> > -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32
> > 
> > I think Eric Engstrom also landed is if-debug patches, so ndebug is by 
> > default
> > only enabled for debug and debugoptimized builds now. I think.
> 
> Other way around: b_ndebug is false by default and can be manually set
> to true, or to if-release in which case it is true if buildtype=release,
> but still false for debugoptimised, debug, minsize and plain unless
> specified.

ndebug makes my head hurt. I really wish that meson would have called the option
"b_assert" so it could be true for asserts on and false for asserts off. You
know what, I'm going to go propose that right now.

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] Lets talk about autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-09-18 08:56:30)
> Dylan Baker wrote on 9/18/18 5:35 PM:
> > Quoting Kai Wasserbäch (2018-09-18 07:43:08)
> >> Hey,
> >> Dylan Baker wrote on 9/17/18 6:44 PM:
> >>> I feel like for !windows meson is in good enough shape at this point that 
> >>> we
> >>> can start having the discussion about deleting the autotools build. So, 
> >>> is there
> >>> anything left that autotools can do that meson cannot (that we actually 
> >>> want to
> >>> implement)? And, what is a reasonable time-table to remove the autotools 
> >>> build?
> >>> I think we could reasonably remove it as soon as 18.3 if others felt 
> >>> confident
> >>> that it would work for them.
> >>
> >> How do I set a specific llvm-config name to look for? I have build 
> >> environments
> >> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far 
> >> I
> >> could convince each build system with LLVM_CONFIG or similar means to 
> >> choose a
> >> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
> >>
> >> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
> >> particular
> >> llvm-config-${VERSION} to llvm-config in $PATH
> >> ().
> >> But I think this should be fixed properly before making meson mandatory. 
> >> Other
> >> modern build systems like CMake react to something like -DLLVM_DIR during
> >> configure (see
> >> ) and 
> >> Mesa's
> >> stable build systems use LLVM_CONFIG, if set.
> >>
> >> Cheers,
> >> Kai
> > 
> > This is something we've discussed upstream several times. I will freely 
> > admit
> > that llvm-config is a huge pain in the ass to deal with for a ton of 
> > reasons,
> > and since we don't use it at Intel
> 
> Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no 
> longer
> the case?

Our relationship with the KBL-G is complicated :)

> > it hasn't been on the top of my list of
> > things to do, and also because the solution upstream wants is very 
> > non-trival to
> > implement. This has come up already and I am working on it right now.
> 
> If upstream support is unreasonable, I'd like to see a similar solution to
> LLVM_CONFIG as it's in autotools today. It must be possible to mangle/override
> the meson variables right? (This might be totally ignorant, because I was able
> to avoid Meson so far and all other build systems I've worked with, have one 
> or
> more options to set variables. Either by having an option in the build files 
> or
> by passing some option into the configure step.)

It really isn't, the only way we could really override this today is to allow
you to pass a version requirement. One of the guiding ideas of meson is that
complicated logic like "how the hell do you make a tool as
broken-by-design-and-implementation as llvm-config work" should be part of meson
itself and not in the local build-system. The downside of that is that upstream
really wants you to think about how you handle things like overriding a specific
binary like llvm-config because it has to live with that decision for a long
time.

> > The other option you have it to set the $PATH variable, as long as the
> > llvm-config you want returns the highest version things will work as you 
> > expect.
> 
> This might do as a workaround, though I'm not too keen on extending $PATH. But
> as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain that
> versions binaries, putting it first into the path could work.

meson will cache the llvm-config values, so you should be able to just do
something like:

PATH=/path/to/my/llvm meson build-with-my-llvm

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] Lets talk about autotools

[Dylan Baker]

Quoting Chuck Atkins (2018-09-18 08:00:44)
> First, I'm fully in support of killing off autotools woo-hoo to that.  And
> given the substantial investment already put into the meson build that
> certainly seems like a good direction to go.
> 
> That being said, the way "auto" is currently implemented leaves quite a bit to
> be desired.  One of the nice features of the Autotools build was how
> auto-enabled options were treated in that the dependencies were searched for
> and if they were all found and met then the option would be enabled.  My
> experience so far with the meson build has shown this not to be the case and a
> "configure" with no options has yet to be successful for me.  Many of the
> 'auto' options are treated as 'set to true if your platform supports it'
> regardless of whether your system has the requisite dependencies available. 
> For example"
> 
>   • The 'gallium-va' option defaults to 'auto' but the implementation ends up
> setting the '_va' option to true if the other option conditions are met,
> long before libva is searched for.  So then when libva isn't found one 
> gets
> an error.
>   □ if set to auto then missing the libva dependencies should be a 
> failure,
> it should just disable the gallium va state tracker

This is a bug I noticed earlier, I think I have a patch for it I just never sent
out apparently. I've send that out now.

>   • The platform options set to 'auto'  has a set of checks to determine which
> platforms are enabled as required.  If the system_has_kms_drm check is 
> true
> then Wayland is enabled as required.  Later if the check for wayland
> dependencies fails, an error occurs.
>   □ If platforms are set to auto then a failure to locate dependencies for
> a given platform should disable the platform.
> 
> I realize these are just two specific examples, each of which can be readily
> dealt with in their own specific way so I'm not asking "how to I address #1 
> and
> #2?" because I can certainly do that.  These are just two instances of many
> though in the way "auto" is dealt with.  My point is really a broader one that
> before meson becomes the primary build then the behavior of "auto" should
> create a successful configure out of the box without additional options. 

This is a much harder thing to fix, I'll look into it, but it'll take at least a
few days to get this done.

> 
> --
> Chuck Atkins
> Staff R Engineer, Scientific Computing
> Kitware, Inc.
> 
> 
> On Tue, Sep 18, 2018 at 9:04 AM Eric Engestrom 
> wrote:
> 
> On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:
> > Where do I find default values for meson configure options?
> 
> If you mean the project's options, they're in meson_options.txt;
> currently not printed in the output of `meson configure` though.
> 
> If you mean Meson's own options (like `buildtype`), I don't think that
> information exists anywhere outside of Meson's source code (and it's
> affected by meson.build too).
> 
> It might be worth opening an issue upstream to ask for and track the
> progress of this feature if you want it :)
> 
> >
> > Thanks,
> > Marek
> >
> > On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker 
> wrote:
> > > I feel like for !windows meson is in good enough shape at this point
> that we
> > > can start having the discussion about deleting the autotools build. 
> So,
> is there
> > > anything left that autotools can do that meson cannot (that we 
> actually
> want to
> > > implement)? And, what is a reasonable time-table to remove the
> autotools build?
> > > I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> > > that it would work for them.
> > >
> > > 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
> ___
> 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] Lets talk about autotools

[Eric Engestrom]

On Tuesday, 2018-09-18 08:24:52 -0700, Dylan Baker wrote:
> Quoting Kenneth Graunke (2018-09-18 01:40:48)
> > On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> > > Quoting Marek Olšák (2018-09-17 15:14:11)
> > > > How do I build 32-bit Mesa with meson?
> > > > 
> > > > Thanks,
> > > > Marek
> > > > 
> > > 
> > > Some people get away with just adding CFLAGs=-m32, but using a cross file 
> > > and
> > > doing a cross build is a better way, and is basically required if you 
> > > want llvm.
> > > Here's mine: https://gitlab.freedesktop.org/snippets/504
> > > 
> > > Dylan
> > 
> > I've attached mine, I then do:
> > 
> > meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
> > --prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
> > -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
> > build/32
> > 
> > Other than the addition of --cross-file, it's just like any other build.
> 
> If you put your cross file in ~/.local/share/meson/cross then you could just 
> do
> 
> meson --cross-file=meson-32-cross --buildtype=release 
> --prefix=$PWD/build/32/install -Ddri-drivers=i965 -Dvulkan-drivers=intel 
> -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32
> 
> I think Eric Engstrom also landed is if-debug patches, so ndebug is by default
> only enabled for debug and debugoptimized builds now. I think.

Other way around: b_ndebug is false by default and can be manually set
to true, or to if-release in which case it is true if buildtype=release,
but still false for debugoptimised, debug, minsize and plain unless
specified.

> 
> 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] Lets talk about autotools

[Kai Wasserbäch]

Dylan Baker wrote on 9/18/18 5:35 PM:
> Quoting Kai Wasserbäch (2018-09-18 07:43:08)
>> Hey,
>> Dylan Baker wrote on 9/17/18 6:44 PM:
>>> I feel like for !windows meson is in good enough shape at this point that we
>>> can start having the discussion about deleting the autotools build. So, is 
>>> there
>>> anything left that autotools can do that meson cannot (that we actually 
>>> want to
>>> implement)? And, what is a reasonable time-table to remove the autotools 
>>> build?
>>> I think we could reasonably remove it as soon as 18.3 if others felt 
>>> confident
>>> that it would work for them.
>>
>> How do I set a specific llvm-config name to look for? I have build 
>> environments
>> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
>> could convince each build system with LLVM_CONFIG or similar means to choose 
>> a
>> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
>>
>> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
>> particular
>> llvm-config-${VERSION} to llvm-config in $PATH
>> ().
>> But I think this should be fixed properly before making meson mandatory. 
>> Other
>> modern build systems like CMake react to something like -DLLVM_DIR during
>> configure (see
>> ) and Mesa's
>> stable build systems use LLVM_CONFIG, if set.
>>
>> Cheers,
>> Kai
> 
> This is something we've discussed upstream several times. I will freely admit
> that llvm-config is a huge pain in the ass to deal with for a ton of reasons,
> and since we don't use it at Intel

Since there's now an „APU“ from Intel with an AMD GPU, I guess that is no longer
the case?

> it hasn't been on the top of my list of
> things to do, and also because the solution upstream wants is very non-trival 
> to
> implement. This has come up already and I am working on it right now.

If upstream support is unreasonable, I'd like to see a similar solution to
LLVM_CONFIG as it's in autotools today. It must be possible to mangle/override
the meson variables right? (This might be totally ignorant, because I was able
to avoid Meson so far and all other build systems I've worked with, have one or
more options to set variables. Either by having an option in the build files or
by passing some option into the configure step.)

> The other option you have it to set the $PATH variable, as long as the
> llvm-config you want returns the highest version things will work as you 
> expect.

This might do as a workaround, though I'm not too keen on extending $PATH. But
as the /usr/lib/llvm-${LLVM_VERSION}/bin directories should only contain that
versions binaries, putting it first into the path could work.

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] Lets talk about autotools

[Dylan Baker]

Quoting Brian Paul (2018-09-17 20:02:21)
> Hi Dylan,
> 
> I have my 32-bit cross-compile working, but "ninja -C builddir install" 
> isn't putting the 32-bit libs and drivers in the right place.
> 
> I've been playing with the meson --prefix option and the 
> -Ddri-drivers-path=foo option but haven't found the right incantation.
> 
> On Ubuntu, I want the libs and drivers to wind up in 
> /usr/lib/i386-linux-gnu/
> 
> Any tips?
> 
> -Brian

As Marek said, you probably want to set -Dlibdir=i386-linux-gnu, if any of these
paths are relative they're assumed to be relative to your prefix.

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] Lets talk about autotools

[Dylan Baker]

Quoting Kai Wasserbäch (2018-09-18 07:43:08)
> Hey,
> Dylan Baker wrote on 9/17/18 6:44 PM:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is 
> > there
> > anything left that autotools can do that meson cannot (that we actually 
> > want to
> > implement)? And, what is a reasonable time-table to remove the autotools 
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt 
> > confident
> > that it would work for them.
> 
> How do I set a specific llvm-config name to look for? I have build 
> environments
> with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
> could convince each build system with LLVM_CONFIG or similar means to choose a
> particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.
> 
> Eric pointed me to an ugly hack on IRC, which involves symlinking the 
> particular
> llvm-config-${VERSION} to llvm-config in $PATH
> ().
> But I think this should be fixed properly before making meson mandatory. Other
> modern build systems like CMake react to something like -DLLVM_DIR during
> configure (see
> ) and Mesa's
> stable build systems use LLVM_CONFIG, if set.
> 
> Cheers,
> Kai

This is something we've discussed upstream several times. I will freely admit
that llvm-config is a huge pain in the ass to deal with for a ton of reasons,
and since we don't use it at Intel it hasn't been on the top of my list of
things to do, and also because the solution upstream wants is very non-trival to
implement. This has come up already and I am working on it right now.

The other option you have it to set the $PATH variable, as long as the
llvm-config you want returns the highest version things will work as you expect.

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] Lets talk about autotools

[Dylan Baker]

Quoting Ilia Mirkin (2018-09-17 17:56:15)
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker  wrote:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is 
> > there
> > anything left that autotools can do that meson cannot (that we actually 
> > want to
> > implement)? And, what is a reasonable time-table to remove the autotools 
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt 
> > confident
> > that it would work for them.
> 
> I remember there was a particularly egregious failure mode for meson
> where running "meson configure help" would fail if any of the
> dependencies were missing for whatever the default was. Has that been
> resolved? I'd also encourage writing a new "configure" script which
> echo's instructions on how to operate meson -- it's really not
> obvious, with alternating --prefix=bla -Dfoo=bla argument styles.
> People know how to use autotools, but meson is a fairly new thing.
> 
> Cheers,
> 
>   -ilia

I got a patch into (I think) 0.46 that allows the use -D for all options, all
the time. Now you can say `meson build -Dprefix=blah -Dfoo=blah` and it will
work. I think there's some work to refactor the way that argument processing is
handled so that that -- and -D are interchangeable.

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] Lets talk about autotools

[Dylan Baker]

Quoting Kenneth Graunke (2018-09-18 01:40:48)
> On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> > Quoting Marek Olšák (2018-09-17 15:14:11)
> > > How do I build 32-bit Mesa with meson?
> > > 
> > > Thanks,
> > > Marek
> > > 
> > 
> > Some people get away with just adding CFLAGs=-m32, but using a cross file 
> > and
> > doing a cross build is a better way, and is basically required if you want 
> > llvm.
> > Here's mine: https://gitlab.freedesktop.org/snippets/504
> > 
> > Dylan
> 
> I've attached mine, I then do:
> 
> meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
> --prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
> -Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true 
> build/32
> 
> Other than the addition of --cross-file, it's just like any other build.

If you put your cross file in ~/.local/share/meson/cross then you could just do

meson --cross-file=meson-32-cross --buildtype=release 
--prefix=$PWD/build/32/install -Ddri-drivers=i965 -Dvulkan-drivers=intel 
-Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32

I think Eric Engstrom also landed is if-debug patches, so ndebug is by default
only enabled for debug and debugoptimized builds now. I think.

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] Lets talk about autotools

[Chuck Atkins]

First, I'm fully in support of killing off autotools woo-hoo to that.  And
given the substantial investment already put into the meson build that
certainly seems like a good direction to go.

That being said, the way "auto" is currently implemented leaves quite a bit
to be desired.  One of the nice features of the Autotools build was how
auto-enabled options were treated in that the dependencies were searched
for and if they were all found and met then the option would be enabled.
My experience so far with the meson build has shown this not to be the case
and a "configure" with no options has yet to be successful for me.  Many of
the 'auto' options are treated as 'set to true if your platform supports
it' regardless of whether your system has the requisite dependencies
available.  For example"

   - The 'gallium-va' option defaults to 'auto' but the implementation ends
   up setting the '_va' option to true if the other option conditions are met,
   long before libva is searched for.  So then when libva isn't found one gets
   an error.
  - if set to auto then missing the libva dependencies should be a
  failure, it should just disable the gallium va state tracker
  - The platform options set to 'auto'  has a set of checks to
   determine which platforms are enabled as required.  If the
   system_has_kms_drm check is true then Wayland is enabled as required.
   Later if the check for wayland dependencies fails, an error occurs.
  - If platforms are set to auto then a failure to locate dependencies
  for a given platform should disable the platform.

I realize these are just two specific examples, each of which can be
readily dealt with in their own specific way so I'm not asking "how to I
address #1 and #2?" because I can certainly do that.  These are just two
instances of many though in the way "auto" is dealt with.  My point is
really a broader one that before meson becomes the primary build then the
behavior of "auto" should create a successful configure out of the box
without additional options.

--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.


On Tue, Sep 18, 2018 at 9:04 AM Eric Engestrom 
wrote:

> On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:
> > Where do I find default values for meson configure options?
>
> If you mean the project's options, they're in meson_options.txt;
> currently not printed in the output of `meson configure` though.
>
> If you mean Meson's own options (like `buildtype`), I don't think that
> information exists anywhere outside of Meson's source code (and it's
> affected by meson.build too).
>
> It might be worth opening an issue upstream to ask for and track the
> progress of this feature if you want it :)
>
> >
> > Thanks,
> > Marek
> >
> > On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker 
> wrote:
> > > I feel like for !windows meson is in good enough shape at this point
> that we
> > > can start having the discussion about deleting the autotools build.
> So, is there
> > > anything left that autotools can do that meson cannot (that we
> actually want to
> > > implement)? And, what is a reasonable time-table to remove the
> autotools build?
> > > I think we could reasonably remove it as soon as 18.3 if others felt
> confident
> > > that it would work for them.
> > >
> > > 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
> ___
> 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] Lets talk about autotools

[Kai Wasserbäch]

Hey,
Dylan Baker wrote on 9/17/18 6:44 PM:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is 
> there
> anything left that autotools can do that meson cannot (that we actually want 
> to
> implement)? And, what is a reasonable time-table to remove the autotools 
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt confident
> that it would work for them.

How do I set a specific llvm-config name to look for? I have build environments
with multiple LLVM versions (eg. 6, 7 and 8) installed in parallel. So far I
could convince each build system with LLVM_CONFIG or similar means to choose a
particular llvm-config-${LLVM_VERSION], meson can't do that AFAICT.

Eric pointed me to an ugly hack on IRC, which involves symlinking the particular
llvm-config-${VERSION} to llvm-config in $PATH
().
But I think this should be fixed properly before making meson mandatory. Other
modern build systems like CMake react to something like -DLLVM_DIR during
configure (see
) and Mesa's
stable build systems use LLVM_CONFIG, if set.

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] Lets talk about autotools

[Eric Engestrom]

On Monday, 2018-09-17 17:25:36 -0400, Marek Olšák wrote:
> Where do I find default values for meson configure options?

If you mean the project's options, they're in meson_options.txt;
currently not printed in the output of `meson configure` though.

If you mean Meson's own options (like `buildtype`), I don't think that
information exists anywhere outside of Meson's source code (and it's
affected by meson.build too).

It might be worth opening an issue upstream to ask for and track the
progress of this feature if you want it :)

> 
> Thanks,
> Marek
> 
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker  wrote:
> > I feel like for !windows meson is in good enough shape at this point that we
> > can start having the discussion about deleting the autotools build. So, is 
> > there
> > anything left that autotools can do that meson cannot (that we actually 
> > want to
> > implement)? And, what is a reasonable time-table to remove the autotools 
> > build?
> > I think we could reasonably remove it as soon as 18.3 if others felt 
> > confident
> > that it would work for them.
> >
> > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Eric Engestrom]

On Monday, 2018-09-17 18:11:37 -0400, Marek Olšák wrote:
> 'meson configure' returns 'auto' for a lot of options. I'm interested
> in what meson chose.

I actually had a couple patches to get that printed, but it got forgotten.
I'll try to pick it back up, rebase it and send it again :)

> 
> Marek
> 
> On Mon, Sep 17, 2018 at 6:09 PM, Caio Marcelo de Oliveira Filho
>  wrote:
> > On Mon, Sep 17, 2018 at 05:18:52PM -0400, Marek Olšák wrote:
> >> If I configure meson, how can I know which state trackers, APIs, and
> >> backends are enabled?
> >
> > 'meson configure' in the build directory gives you that information
> > (at least some of it).  That might give you some information.  Part of
> > the output looks like
> >
> > Project options:
> >   Option Current Value Possible Values  
> > 
> >   Description
> >   -- - ---  
> > 
> >   ---
> >   asmtrue  [true, false]
> > 
> >   Build assembly code if possible
> >   build-teststrue  [true, false]
> > 
> >   Build unit tests. Currently this will build *all* unit tests, 
> > which may build more than expected.
> >   d3d-drivers-path  
> > 
> >   Location of D3D drivers. Default: $libdir/d3d
> >   dri-drivers[][, auto, i915, i965, r100, r200, 
> > nouveau, swrast]
> >   List of dri drivers to build. If this is set to auto all 
> > drivers applicable to the target OS/architecture will be built
> >   dri-drivers-path  
> > 
> >   Location to install dri drivers. Default: $libdir/dri.
> >   dri-search-path   
> > 
> >   Locations to search for dri drivers, passed as colon 
> > separated list. Default: dri-drivers-path.
> >   dri3   auto  [auto, true, false]  
> > 
> >   enable support for dri3
> >   eglauto  [auto, true, false]  
> > 
> >   Build support for EGL platform
> >   gallium-drivers[iris][, auto, pl111, radeonsi, r300, 
> > r600, nouveau, freedreno, swrast, v3d, vc4, etnaviv, imx, tegra, i915, 
> > svga, virgl, swr, iris] List of gallium drivers to build. If this is set to 
> > auto all drivers applicable to the target OS/architecture will be built
> >   gallium-extra-hud  false [true, false]
> > 
> >   Enable HUD block/NIC I/O HUD status support
> >   gallium-nine   false [true, false]
> > 
> >   build gallium "nine" Direct3D 9.x state tracker.
> >   gallium-omxauto  [auto, disabled, bellagio, tizonia]  
> > 
> >   enable gallium omx state tracker.
> >   gallium-opencl disabled  [icd, standalone, disabled]  
> > 
> >   build gallium "clover" OpenCL state tracker.
> >   gallium-va auto  [auto, true, false]  
> > 
> >   enable gallium va state tracker.
> >   gallium-vdpau  auto  [auto, true, false]  
> > 
> >   enable gallium vdpau state tracker.
> >   gallium-xa auto  [auto, true, false]  
> > 
> >   enable gallium xa state tracker.
> >   gallium-xvmc   auto  [auto, true, false]  

Re: [Mesa-dev] Lets talk about autotools

[Kenneth Graunke]

On Monday, September 17, 2018 3:24:56 PM PDT Dylan Baker wrote:
> Quoting Marek Olšák (2018-09-17 15:14:11)
> > How do I build 32-bit Mesa with meson?
> > 
> > Thanks,
> > Marek
> > 
> 
> Some people get away with just adding CFLAGs=-m32, but using a cross file and
> doing a cross build is a better way, and is basically required if you want 
> llvm.
> Here's mine: https://gitlab.freedesktop.org/snippets/504
> 
> Dylan

I've attached mine, I then do:

meson --cross-file=/home/kwg/.local/meson-32-cross --buildtype=release 
--prefix=/home/kwg/Projects/mesa/build/32/install -Ddri-drivers=i965 
-Dvulkan-drivers=intel -Dgallium-drivers= -Db_ndebug=true -Dglvnd=true build/32

Other than the addition of --cross-file, it's just like any other build.
[binaries]
c = '/usr/bin/gcc'
cpp = '/usr/bin/g++'
ar = '/usr/bin/ar'
strip = '/usr/bin/strip'
pkgconfig = '/usr/bin/pkg-config'

[properties]
c_args = ['-m32']
c_link_args = ['-m32']
cpp_args = ['-m32']
cpp_link_args = ['-m32']

[host_machine]
system = 'linux'
cpu_family = 'x86'
cpu = 'i686'
endian = 'little'

# vim: ft=dosini

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] Lets talk about autotools

[Mathieu Bridon]

On Mon, 2018-09-17 at 20:56 -0400, Ilia Mirkin wrote:
> I'd also encourage writing a new "configure" script which
> echo's instructions on how to operate meson -- it's really not
> obvious, with alternating --prefix=bla -Dfoo=bla argument styles.
> People know how to use autotools, but meson is a fairly new thing.

During its (still unfinished) transition to Meson, the GNOME project
has successfully used configure scripts for compatibility with the
autotools build API.

See this one for example: 
https://gitlab.gnome.org/GNOME/json-glib/blob/8b6c216d60e1d54d9314c00931131fbfa7d15563/configure

With this, you can keep doing the usual ./configure; make; make install
dance and it uses Meson and Ninja under the hood (configure options are
translated to meson options, some work might be needed for custom
options)

It was used to not block the migration to Meson, yet keep building on
those platforms which didn't have Meson yet.

Maybe a similar transition could work for Mesa, temporarily?

Hope that helps,


-- 
Mathieu

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

Re: [Mesa-dev] Lets talk about autotools

[Marek Olšák]

Did you try --libdir /usr/lib/i386-linux-gnu ?

Marek

On Mon, Sep 17, 2018 at 11:02 PM, Brian Paul  wrote:
> Hi Dylan,
>
> I have my 32-bit cross-compile working, but "ninja -C builddir install"
> isn't putting the 32-bit libs and drivers in the right place.
>
> I've been playing with the meson --prefix option and the
> -Ddri-drivers-path=foo option but haven't found the right incantation.
>
> On Ubuntu, I want the libs and drivers to wind up in
> /usr/lib/i386-linux-gnu/
>
> Any tips?
>
> -Brian
> ___
> 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] Lets talk about autotools

[Brian Paul]

Hi Dylan,

I have my 32-bit cross-compile working, but "ninja -C builddir install" 
isn't putting the 32-bit libs and drivers in the right place.

I've been playing with the meson --prefix option and the 
-Ddri-drivers-path=foo option but haven't found the right incantation.

On Ubuntu, I want the libs and drivers to wind up in 
/usr/lib/i386-linux-gnu/

Any tips?

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

Re: [Mesa-dev] Lets talk about autotools

[Brian Paul]

Same here.  I'm working on updating our internal build scripts to use 
Meson.  Working through 32-bit cross compile issues now...

-Brian


On 09/17/2018 07:09 PM, Marek Olšák wrote:
> Other than the --with-sha1 thing, meson works for me.
> 
> That said, we need some time to move our internal builds to meson and
> there is a tiny chance that we'll discover some issues.
> 
> Removing autotools after 18.3 would be preferable.
> 
> Thanks,
> Marek
> 
> 
> 
> On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker  wrote:
>> I feel like for !windows meson is in good enough shape at this point that we
>> can start having the discussion about deleting the autotools build. So, is 
>> there
>> anything left that autotools can do that meson cannot (that we actually want 
>> to
>> implement)? And, what is a reasonable time-table to remove the autotools 
>> build?
>> I think we could reasonably remove it as soon as 18.3 if others felt 
>> confident
>> that it would work for them.
>>
>> Dylan
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbrianp%40vmware.com%7C536f0a42b1fa44b69cc008d61d038d15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636728298426334928sdata=4Rm33SSVQvvUhTazqe7RMUwq%2BvcS1k8gFENhMn28EcU%3Dreserved=0
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-devdata=02%7C01%7Cbrianp%40vmware.com%7C536f0a42b1fa44b69cc008d61d038d15%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636728298426344933sdata=Xh%2FtCw226Rytfv7CbcGiBQE5f3Sj70aZSjtGBdC17wM%3Dreserved=0
> 

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

Re: [Mesa-dev] Lets talk about autotools

[Matt Turner]

On Mon, Sep 17, 2018 at 5:50 PM Marek Olšák  wrote:
>
> One missing feature is --with-sha1=. libcrypto has an unstable ABI and
> Steam uses it. For Mesa to work with Steam, libnettle has/had to be
> used instead.

We imported OpenBSD's sha1 implementation a year and a half ago to
avoid all of that.

commit d1efa09d342bff3e5def2978a0bef748d74f9c82 (tag: 17.0-branchpoint)
Author: Emil Velikov 
Date:   Fri Jan 13 16:51:31 2017 +

util: import sha1 implementation from OpenBSD
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Lets talk about autotools

[Marek Olšák]

Other than the --with-sha1 thing, meson works for me.

That said, we need some time to move our internal builds to meson and
there is a tiny chance that we'll discover some issues.

Removing autotools after 18.3 would be preferable.

Thanks,
Marek



On Mon, Sep 17, 2018 at 12:44 PM, Dylan Baker  wrote:
> I feel like for !windows meson is in good enough shape at this point that we
> can start having the discussion about deleting the autotools build. So, is 
> there
> anything left that autotools can do that meson cannot (that we actually want 
> to
> implement)? And, what is a reasonable time-table to remove the autotools 
> build?
> I think we could reasonably remove it as soon as 18.3 if others felt confident
> that it would work for them.
>
> 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