By default Mesa enables few common 3D drivers.  They can be built if you have their dependencies installed.

Mesa doesn't try to guess for which HW you want to build your driver, because your build machine isn't necessarily the one where the driver is going to be used.

If you don't want to build them, you need to tell Mesa that, e.g. with: "--with-dri-drivers=swrast --without-gallium-drivers".  I.e. this is user error.

So far there aren't ARM machines with Integrated Intel gfx in them (although reverse is true).  Although it's an unlikely use-case, it's possible to use ARM machine to cross-build Intel version of Mesa, so host checking isn't enough, potential check for disabling Intel backends on ARM needs to check target architecture.

If you have patch for this, I guess it could get integrated.

Fwiw I would like to get things to the point of either:
 - enable the drivers that have their dependencies resolved
 - or, enable all drivers by default.

I'm split between the two, but I'm strongly against "dest. system is ARM, let's disable intel, radeon, nouveau, etc." drivers approach.

As Eero mentioned - patches will be greatly appreciated.

(In reply to Emil Velikov from comment #2)
> Fwiw I would like to get things to the point of either:
>  - enable the drivers that have their dependencies resolved
>  - or, enable all drivers by default.
> 
> I'm split between the two, but I'm strongly against "dest. system is ARM,
> let's disable intel, radeon, nouveau, etc." drivers approach.

I sent patches once (and am still partial to) requiring users to specify which drivers they want.

Developers and distributions know which driver(s) they want to build. The only use-case I heard that this wouldn't handle is the "I just want to build test everything and I don't want to have to look up what everything means" which honestly doesn't strike me as a serious issue, but also one that should be easily solvable.

I would close this as not a bug. People are supposed to read error messages and either install missing dependencies or adjust configure parameters accordingly.

The remarkable thing about this was that an unlikely target and dependent library was picked by default.

Cross compiling on an cubieboard for an Intel part is unlikely in the extreme. What is most likely is compiling for the cubieboard. Oftentimes, configure gets it perfectly right for doing something in the native environment without parameters.

If the configure can't figure out what the user wants from something in the environment, defaulting to an unlikely case makes the user think that something is broken, as I did. 

It would make sense that once the "checking for INTEL... no" was emitted, no other diagnostics applicable to INTEL would be issued, such as "No package 'libdrm_intel' found". My reasoning is: intel isn't the platform, checking for a package required to support intel doesn't mean anything, so saying that it's missing doesn't add anything to the picture.