[Mesa-dev] Lets talk about autotools

Mon Dec 3 20:10:46 UTC 2018

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 <dylan at pnwbakers.com> wrote:
> >>>>
> >>>> Quoting Emil Velikov (2018-12-03 07:54:38)
> >>>>> Hi all,
> >>>>>
> >>>>> On Thu, 29 Nov 2018 at 17:44, Emil Velikov <emil.l.velikov at 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&arch=ppc64el&ver=18.3.0%7Erc5-1&stamp=1543575640&raw=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 CC you? We'll need to make sure we have fixes tags so they get
pulled into stable as well presumably.

> 
> (to match configure.ac) 
> 
> And that ppc64el build fail might be because it for some reason doesn't seem to get -DUSE_PPC64LE_ASM..

(assuming that should be ppc64le) We probably are missing an endian check, I'll
look at that in a minute.

Dylan

> 
> 
> 
> -- 
> t
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181203/a0a9afae/attachment-0001.sig>