On Thu, Mar 28, 2019 at 06:13:01PM -0500, Bruce Dubbs via blfs-dev wrote:
> In mesa, I did 'mesaon configure' to see the options it understood.
> What I got was virtually unreadable due to really, really bad formatting
> for the mesa specific options.
>
> Attached is an edited version that is at least a little readable.
>
> -- Bruce
Thanks, I'll mention that command when I update the details of
building things.
ĸen
> Option Current Value Possible Values Description
> ------ ------------- --------------- -----------
> b_asneeded true [true, false] Use -Wl,--as-needed when
> linking
> b_colorout always [auto, always, never] Use colored output
Actually, that seems to be a lie - if I pipe the output and tee it
to a file, both what the screen shows and what is in the file are
readable monochrome (no escape characters), but if I run meson and
just send the output to the screen then I get colours (I had to
scrollback last night to see what the initial red was all about).
>
> Project options:
> Option Current Value Possible Values Description
> ------ ------------- --------------- -----------
> asm true [true, false] Build assembly
> code if possible
> build-tests false [true, false] Build unit tests.
> Currently this will build *all* unit tests,
> which may build more than expected.
LOL.
> d3d-drivers-path Location of D3D drivers. Default: $libdir/d3d
> dri-drivers [i915, i965, nouveau]
> [, auto, i915, i965, r100,
> r200, nouveau, swrast]
> List of dri drivers to build. If this is set to auto i
> all drivers applicable to the target OS/architecture will be
> built
We could specify auto ?
> gallium-drivers [radeonsi, nouveau, svga, swrast] [, auto, kmsro,
> radeonsi,
> r300, r600, nouveau, freedreno, swrast, v3d, vc4,
> etnaviv,
> tegra, i915, svga, virgl, swr]
> List of gallium drivers to build. If this is set to
> auto all drivers
> applicable to the target OS/architecture will be built
Ditto (if all the deps are in place)
> libunwind auto [auto, true, false]
> Use libunwind for stack-traces
Yeah, I already noticed that is a possible dep.
> llvm auto [auto, true, false]
> Build with LLVM support.
Needed for radeonsi and amdgpu, I think ?
> osmesa gallium [none, classic,
> gallium] Build OSmesa.
> osmesa-bits 8 [8, 16, 32]
> Number of channel bits for OSMesa.
> platforms [x11, wayland, drm] [, auto, x11, wayland,
> drm,
> surfaceless, haiku,
> android] window systems to support. If this is set to `auto`,
>
> all platforms applicable will be enabled.
So again, we could just use auto if all the deps are there ?
A lot of information to digest, and some of it is unexpected. Note
that while using 'auto' on a developer's machine might be fine, most
users probably only build for a small subset of devices so I doubt
it is a useful option for our users.
Thanks again, I'll need to think about some of these options.
ĸen
--
It is said that there are two great unsolved problems in computer
science: naming, cache invalidation, and off-by-one errors.
-- Ben Bullock
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
