[Mesa-dev] [PATCH] build: Disable building of d3d1x

[Stéphane Marchesin]

On Fri, Sep 7, 2012 at 8:19 AM, Matt Turner <mattst88 at gmail.com> wrote:
> On Fri, Sep 7, 2012 at 3:30 AM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> ----- Original Message -----
>>> On Thu, Sep 6, 2012 at 11:39 PM, Jose Fonseca <jfonseca at vmware.com>
>>> wrote:
>>> > Matt,
>>> >
>>> > I see you went ahead and just disabled it. Please remove it all
>>> > together.
>>> >
>>> > Touching code that is not built nor tested ends just silently
>>> > introduces bugs, so keeping this around won't help bring it back
>>> > one day in any way.
>>> >
>>> > Jose
>>>
>>> I talked with both Marek and Christoph, and they both said they'd
>>> prefer to simply disable the build. I don't feel strongly, but if
>>> someone is to revive it it'd be nice if we didn't make the git
>>> history
>>> harder to follow.
>>
>> I suppose they have their arguments, and I hope they include making this build again shortly.  What I don't understand is why these talks didn't happen within this email thread. I'd expect at least a heads up email before committing this...
>
> I don't know why they didn't respond via email.
>
> It's not like we can't still remove d3d1x...
>
>>> Applying your reasoning (which I tend to agree with) to some other
>>> parts of Gallium makes for interesting conversation. The VAAPI state
>>> tracker and targets aren't built. Should we also nuke them? How about
>>> something like the xorg-i915 target (which installs a
>>> 'modesetting_drv.so')?
>>
>> I don't know enough about this code or the ongoing autotool-ification process to tell whether this is a short term or long term condition.
>
> VAAPI is disabled in the build system because it doesn't work.
>
>> But yes, In general I see no point in carrying around stuff that doesn't minimally work or can't even be built. If something is unusable/unmaintained over one Mesa release cycle, then it should be chopped off.  Every dead code we remove means that cleanups and refactorings of the good code becomes easier. And if it is broken, then there's no loss to the end user either.
>>
>> This is not the first or last time we'd remove code BTW. There are many precedents.
>
> I know. I'm asking about things that are currently disabled (VAAPI
> stuff) or are of questionable use (xorg-i915).

Make sure you check with Jakob first, but I'm fine with removing
xorg-i915. I don't think it has worked properly in a while.

Stéphane