[Piglit] [PATCH] Make piglitutil library API-independent

[Chad Versace]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/26/2012 05:56 AM, Blaž Tomažič wrote:
> On pet, 2012-06-22 at 15:12 -0700, Chad Versace wrote:

> I have received an email from Eric Anholt about the patches (don't know why he didn't cc the mailing list, he
> probably forgot)

He has been doing that to everyone recently. I suspect he accidentally broke his email client's config.

> and he raises a question why do the new files have '-common' in their names (piglit-util-gl-common.[ch]). I named
> them this way because they have code common to gl and gles. But while we can't have code from
> piglit-util-gl-common.c in piglit-util-gl.c (because then the contents should be copied to piglit-util-gles.c too),
> we can have the gl/gles utilities header in piglit-util-gl.h instead of piglit-util-gl-common.h. So which name 
> should we use for the header?

I think piglit-util-gl-common.c is a reasonable name for that file. I can think of no better. It's name clearly
indicates what it defines: utility functions common to all GL API's.

As for piglit-util-gl-common.h, I'm uncertain if that is the best name, but I can think of no better.

I think piglit-util-gl.h is a bad choice. It obfuscates the naming convention that you establish in this series: files
named *-gl.[ch] provide utilities for GL (not GLES), and files named *-gles.[ch] provide utilities for GLES (not GL).
To name a common header *-gl.h may be more convenient for the test writer (it saves 7 characters), but is inconsitent
with that convention. I prefer consistency to convenience here, and would rather not introduce the inevitable
confusion that would result from naming the file piglit-util-gl.h.

It is a little odd that piglit-util-gl-common.h declares many symbols that are used only by GL (not GLES) tests.
However, I feel that is reasonable because it's the *common* header that GL/GLES tests use to import utilities, and
hence it is appropiate for it declare things for both API's.

As a side note, I want to point out that many of functions in piglit-util-gl.c are implemented very similarly to their
counterparts in piglit-util-gles.c. It would be nice to refactor things so that the GL and GLES versions share a
common definition in piglit-util-gl-common.c without ugly #ifdef hacks. However, I think your approach was the right
approach: let's first clean things up by separating GL, GLES, and common code into separate files, and then someone
(maybe me) can come along in the future and do GL/GLES unification where possible.

> Before submitting a pull request should I rebase my commits for patch on master HEAD to check that there aren't any
> new includes that involve the old headers?

Yes, that's a good idea.

- -Chad

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP6jUeAAoJEAIvNt057x8iz9QP/1eGmLnsGBImtdRooMsBoxMP
gbZsVMjdDi8UtwojIJNOOXKba6YPXxCdt0H/PJ41RafHArdW47PYdmw0ZcJvqKxs
Ga7UfMfwReRT1hGaB8jCmZjnAAvXE7qXSgwh9PCJIBQajh6G062A88o0z+jHcxk7
JPX75KsyQyDwwlxZpZ3buiacZXtw4XCLvgqHo3EBRWZhKqeEwENNa5GjSn8MaaAN
hJvSWBDoBXERVdvAKRxAcH9xbxOf1t2Tf3/fEOfknR0t/ntSfedEYzji5esbaXxF
f5Szt/AbBYNVAZ5C+tlipCf8mHSCNTKvI7syWz2fvvcFze4Z0uTLHk8XKZRRpmlm
5IFI68RDwfIfU3Cos2IdEwNXsdP1rCKUY9mBEoqtpwNtrJDXCwSnaZ4VyT2Ux/bx
1WSodz0wdZNfralbokPoZMUK/MWF9bfn+PrfyZ6q926Cv7964CIOjcMXvmZ/bZnc
doKPsfuR2cCrTQsWoJZSAhLMf4ekZZlAEbzV9rsY594uyWTg56b051/eZuutfBnV
daDG+Mkw1Ji3+27xQt1hqXDELVNktOYjrGw6Ki13DXZXg2Ywe+3bhEP4kAD++G2M
x3VnDQNP3rgMleoyD6XjMAavp6s5rNKs4CRF4Z3Q3Cdp7dFqjM91I+uXSMluNrWx
+mEESmYmUjbdGesUKFZ/
=JhMu
-----END PGP SIGNATURE-----