[Mesa-dev] [RFC PATCH 0/5] last call for autotools (meson travis fixes)

[Emil Velikov]

On Wed, 12 Dec 2018 at 17:13, Dylan Baker <dylan at pnwbakers.com> wrote:
>
> Quoting Emil Velikov (2018-12-12 04:16:51)
> > On Wed, 12 Dec 2018 at 07:45, Rhys Kidd <rhyskidd at gmail.com> wrote:
> > >
> > > Emil and Dylan,
> > >
> > > I took a go at addressing the limited number of remaining meson-based
> > > travis-ci errors. This series applies on top of the work Dylan circulated
> > > yesterday, and which can be seen here:
> > >
> > > >  Could you help me debug my WIP of porting the autotools tests
> > > >  to meson? They're just failing randomly with no good debuging output:
> > > >
> > > >  https://travis-ci.org/dcbaker/mesa/jobs/466665289
> > >
> > > Dylan, if you pick these patches up you may want to squash those ones which
> > > are 'Fixes' into the respective initial patch before any final push.
> > >
> > > At this stage the failures are deterministic.
> > >
> > > The remaining two known issues are:
> > >
> > >   * -Dbuild-tests=true: anv is unable to build when this option is enabled.
> > >     This is unrelated to this series and occurs in master. At present meson
> > >     by default has different test coverage to autotools. See further here:
> > >     https://travis-ci.org/Echelon9/mesa/builds/466840665
> > >
> > The libvulkan_intel_tests (the tests library) is missing the WSI (et
> > al) dependencies. A quick check is to add anv_deps instead of
> > hand-rolling it.
>
> the tests lib does use anv_deps, the only difference I can see between the test
> lib and the actual installed lib is that the installed one link_whole's the
> gen_libs and the test one doesn't.
>
Correct - I misread the code. The only difference is libanv_gen_libs -
which doesn't make a difference.

Although I may have discovered a deeper bug - seems that the locally
built dependencies (xcb, etc) are not picked by the linker.
Even though meson/ninja passes them via absolute names.

I've got a trivial workaround in place, although building the tests
have flagged a few issues more.
I'll finish it today, regardless of the time, and send a decent size series.

> >
> > >   * gallium pipeloaders: There's an ongoing scoping problem with the LLVM
> > >     libraries as a dependency. I was unable to fix yet. See further here:
> > >     https://travis-ci.org/Echelon9/mesa/jobs/466861661#L9112
> > >
> > Suspecting that the dep_llvm in libgallium
> > (src/gallium/aux/meson.build) should be switched to whole_libraries.
> > As-is things get discarded (since they're unused), when creating the
> > static library. Thus as the final stage creating the pipe-driver DSOs
> > we're missing the -lLLVMfoo
> >
> > Not 100% sure on the latter one - will need to play with it.
> >
> > -Emil
>
> You can't link_whole a dependency, it's you can only link whole a library
> (shared or static). I think the "right" solution is to bump to 0.46 and make use
> of the `dependency.partial_dependency` so we can create a `dep_llvm_headers` and
> only link with llvm in the final dsos instead of linking it in everywhere. At
> least, that's part of the motivation I had to write the partial_dependency
> method :)
>
> In the short term what we probably should do is add dep_llvm to the driver_*
> definitions that use llvm (r600, radeonsi, llvmpipe, swr) so that the targets
> pick up the llvm dependency.
>
Thanks will try that one.

-Emil