[Mesa-dev] Lets talk about autotools

Tue Dec 4 07:26:23 UTC 2018

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 <dylan at pnwbakers.com> 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 <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
> >
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

-- 
Stuart Young (aka Cefiar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181204/0691718b/attachment-0001.html>