On 20 March 2012 07:11, Jose Fonseca <span dir="ltr"><<a href="mailto:jfonseca@vmware.com">jfonseca@vmware.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="h5">IMO the biggest CON is that, because specs and implementations vary in subtle ways, aliases cannot be trusted to be truly interchangeable. So a mechanism that fully abstracts aliases is a) introducing a hidden variability factor, b) makes it easy to forget to check the differences.<br>
</div>
<br>
That said, I agree with you, we don't need to throw the baby with the water, and we can still have a code generation for handling aliases while still maintain close control over which extension is used, as some of your ideas achieve.<br>
<br>
I'm happy to let you decide what you think it's best here.<br></blockquote><div><br>Ok, thanks. I will plan to keep the code as is for the initial commit, and I will try some of the ideas we've talked about as follow-up patches.<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
> Incidentally, some of us at Intel have been tossing around the idea<br>
> of doing away with all.tests altogether, and instead annotating the<br>
> individual .c files with specially-formatted comments indicating how<br>
> each test should be run (much as we already do for GLSL parser<br>
> tests). If we did that, then it seems like it would be fairly easy<br>
> for every test to specify which combinations of GL versions and<br>
> extensions it supports, and the piglit framework could automatically<br>
> invoke it multiple times if necessary to test each set of aliased<br>
> functions. If we went with this approach, it would have the<br>
> additional advantage that the piglit framework could take<br>
> responsibility for skipping tests that don't apply to the current<br>
> implementation, rather than being forced to each of those tests<br>
> individually and collect their "skip" results.<br>
<br>
</div><br>Sounds a very nice idea.<br></blockquote><div><br>Thanks for the feedback. I'll try to keep the conversation going about this in the next several weeks.<br></div></div>