<div dir="ltr"><br><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 1, 2013 at 1:10 PM, Ian Romanick <span dir="ltr"><<a href="mailto:idr@freedesktop.org" target="_blank">idr@freedesktop.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">While you're on a kick of fixing these kinds of issues... I have some<br>
problems on my system because my GLES libraries and header files aren't<br>
in the usual place.  There's some support for glext.h being in a<br>
nonstandard place, but it would be nice if the others could be as<br>
well... of it would just use glesv1_cm.pc, glesv2.pc, and gl.pc without<br>
manual intervention.<br>
<br>
I accidentally pushed (and reverted) one of my local build fixes<br>
(271d065) recently, but it's just a hack.<br>
<div class=""><div class="h5"><br></div></div></blockquote></div><br><br>These commits are to avoid using any hacks while maintaining maximum compatibility.<br><br><br></div><div class="gmail_extra">Fix 1) Out of tree generated files installation.<br>
<br></div><div class="gmail_extra">Clearly not everybody installs piglit using an out of source build, but this is a common practice in development to avoid putting garbage in the source tree. This uses as little code as possible to fix the problem and is easily traced back to wiki documentation for CMake [1]:<br>
<br>CMAKE_BINARY_DIR  -  if you are building in-source, this is the same as CMAKE_SOURCE_DIR, otherwise this is the top level directory of your build tree <br></div><div class="gmail_extra"><br>CMAKE_SOURCE_DIR - this is the directory, from which cmake was started, i.e. the top level source directory<br>
<br></div><div class="gmail_extra">This is the cleanest fix possible since when building out of tree, the generated tests do not appear in the source tree, but instead the build tree. (NOTE: You can also look at the Cmake 2.6 documentation[2] at these variables and it'll be the same )<br>
<br></div><div class="gmail_extra">NOTE: A todo on this is to have piglit run automatically set the path directory to the folder where piglit script is located at.<br><br></div><div class="gmail_extra">Fix 2) STRNDUP definition<br>
<br>Not a lot can be said about this, but it's the only way to fix compilation on platforms that already implement and declare strndup.<br><br></div><div class="gmail_extra">fix 3) Update Cmake from 2.6 to 2.8<br></div>
<div class="gmail_extra"><br>This update should not be a shock to the masses. This honestly is bringing a little uniformness to piglit since Linux has required CMake for over a year now. This was introduced in the patch that requires Waffle to be installed on linux. [3]<br>
<br></div><div class="gmail_extra">Fix 4) Add missing installation files.<br><br></div><div class="gmail_extra">Yet another small fix. These probably should have been done by the implementer that added these tests to begin with, however it appears to be common practice to only test piglit with in-source builds and to never try installing piglit. This is what leads to these patches. <br>
<br></div><div class="gmail_extra">TIP: It may not sound like much, but being able to install and package piglit is a good idea since it'll allow larger organizations to be able to verify overall test results over a larger set of configurations without having to continually compile and install piglit on each individual machine. I know for a fact that this would be a nightmare on a lot of older computers or netbooks where all they are trying to do is find out if the driver is behaving the same overall.<br>
<br><br></div><div class="gmail_extra">Fix 5) Fix the opengl extension string usage.<br><br></div><div class="gmail_extra">This may not sound like a lot, and Chad has already reviewed this originally. However this is a minor fix to reset the extension string when you run into a context fallback. For example when you try OpenGL 3.1 core and then fall back to the OpenGL 3.1 Compatiblity profile. It would stand to reason that when you do run this fall back that it would be impractical to expect the extension string on both contexts to be the same. It would be best to expect that the string changes because the Compatibility profile would expose the extension string entry of GL_ARB_compatibility and the Core profile will not have this extension.<br>
</div><div class="gmail_extra"><br>[1] CMake Useful Variables<br><a href="http://www.cmake.org/Wiki/CMake_Useful_Variables">http://www.cmake.org/Wiki/CMake_Useful_Variables</a><br><br>[2] CMake 2.6 Documentation<br><a href="http://www.cmake.org/cmake/help/cmake2.6docs.html">http://www.cmake.org/cmake/help/cmake2.6docs.html</a><br>
<br>[3] Piglit Git repository: cmake: On Linux, require Waffle by default<br><a href="http://cgit.freedesktop.org/piglit/commit/CMakeLists.txt?id=4072eacd585d084d443a9643bb864160ea71494b">http://cgit.freedesktop.org/piglit/commit/CMakeLists.txt?id=4072eacd585d084d443a9643bb864160ea71494b</a><br>
</div></div></div>