Best practice for wrapping up OGLES2Tools into your own project

PowerVR Insider
1

Hi all,



I currently have the OGLES2Tools project as a subproject in Xcode. This is not changed, so I have been referencing the SDK source in its default location and leaving it locked for editing.



I recognise there are a few problems with this approach:


  1. My checked-in code depends on something that is in a particular location on MY machine. If/when I have another team member they would have to checkout my code then install my targeted version of the PVRSDK and make sure the source files were in the same place as they are on my machine - this is obviously not good.


  2. How do I tie my code to a particular version of the SDK?



    The obvious solution these problems seems to be to create a subfolder under my main project folder (called pvrsdk or something) and put a copy of the OGLES2Tools source in there. Then use that (project folder relative) location as the place where xcode finds the subproject. This would mean that I would be committing my targeted version of the SDK to git along with the rest of my code.



    Does this approach sound familiar, if not what do people usually do?



    Kind regards,



    Andre.
2

Hi Andre,



For our Utilities that utilise the PVRTools framework, we use Cmake to generate Visual Studio, XCode and Linux Makefiles. The dependent projects are referenced in Cmake files by their relative path. There are plenty of other makefile generation tools out there, but Cmake has worked well for us.



I’d recommend checking the PVRTools source into your repository. Many developers do this with a “3rdparty” directory in their root that contains the PVRTools framework and similar dependencies they may have. This approach also has the benefit that if, for any reason, you need to modify the PVRTools framework, you can easily track your changes and diff them against the original code that was added to your repository.



We’re working on a redesigned framework for a future SDK release. The new framework will be much more modular, which will make it easier for developers to pick and choose the components that should be integrated into their code.



Regards,

Joe

3

Thanks Joe,



I thought that would be the right way to go, but it’s nice to get it “from the horse’s mouth” so to speak :slight_smile:



Regards,



Andre.