mesa-lib

[Dennis Veatch]

On 06/19/2012 07:56 AM, Jean-Michel Bruenn wrote:
>>> Why don't you provide/submit/commit a patch that works for you
>>> and removes some of the weird logic from BUILD?
>>> I'll gladly push it to moonbase, if you submit it or send it via mail.
>> Here is a better idea; let the one(s) that made the commit fix it, or is
>> that to much to ask?
> Thats the problem we're facing with at lunar linux. Nobody feels
> responsible for bugs introduced by devs who didn't test properly.

It is the reason for my hiatus.

Sure, something will always slip by; acknowledged.

However, after a while it becomes tiresome to fix commits such as the 
one I linked to.  Many times in IRC and in my commits I have stated if 
there are any problems let me know and I will fix them. In other words; 
when I make a commit, I take/have assumed responsibility for that commit 
and the consequences it may have.  All I am asking for is a little more 
of that to percolate through the commit process.

> Which is, what my approach using "stable" should solve. But to
> work that would actually require developers (all of them) to
> feel responsible again for _every_ bug and solve those in stable.

Yes if it would work that way. Speaking of stable and should it be 
implemented; who will devote the time and be the Gate Keeper? If it 
turns out as catch as catch can, I don't see that as being any better.

> However; for the mesa-issue this is tricky, because we need a few
> work-arounds:
>
> 	r300 will only work with llvm.
> 	gallium requires (because we use such a configure switch)
> 		llvm
> 	swrast should be included always however, it should be
> 		made optionally again.
> 	egl should be choosable, though i don't know how much sense
> 		it does on a non-atom cpu.
>
> First try: llvm removed, lin mesa-lib, said no to dri (all drivers will be build) said no to gallium:
>
> configure: error: LLVM is required to build Gallium R300 on x86 and x86_64
>
> second try, said y to select drivers, said n to gallium - same error message.
>
> third try, i changed the module to contain --with-gallium-drivers=swrast" if one says no to gallium - now compiling works, without llvm.
>
> what i want to point out is, this module needs a lot of love to work correctly. What we'd need to do (if we still want to be smart) is:
>
> First ask the user which dri drivers he want to use - Make sure he can choose swrast and add "RECOMMENDED" behind it.
>
> Now ask the user if he plans to use r300 or another driver which requires llvm. If yes get/install llvm.
>
> Now ask the user if he plans to use gallium, if yes check if llvm is installed, if yes set --enable-gallium-llvm, if not set it --disable. If the user does not want to use a specific gallium driver - just do --with-gallium-drivers=swrast, if he wants to use a specific gallium driver, let him select that and again let him choose if he wants swrast or not - it's recommended though.
>
> then finally make configure switches for various other things...
>
> It's not that easy...
> _______________________________________________

Haven't looked at the module in detail but on the surface that sounds 
reasonable. Perhaps as a default make VESA a default driver. AFAIK that 
does not require a ton of other crap and still provides a display should 
a video card need changing... for whatever reason it may be.

Dennis Veatch