Git and I
Within the last year, I’ve started to use Git (a distributed version control system) to manage changes to my personal and academic projects. If you’ve used SVN or CVS before, the basic concept of storing multiple versions and committing changes is similar, but it’s otherwise a bit different: with Git, branching and merging is cheap (time-wise) and very easy, so you’re encouraged to branch and merge often. This fosters a healthy “keep the master (trunk) branch stable” habit while you continue development of features, each in their own branch. Additionally, Git has a concept of “staging” your changes – it doesn’t commit all of your modifications by default, so you can make sure that each commit is “atomic” – that it accomplishes only one thing. Even when doing weekly class assignments now, I use Git as a way to track my progress, incentivize rapid progress (committing changes gives a rush of energy), and store working versions without making many messy copies of my source directory. Read on for what I’ve learned and how to get started! (more…)
I recorded a brief screencast for the benefit of my classmates who would like to work in the X-Code environment on the Mac (for editing, building, and debugging) for their ME/CprE 557 assignments.
You can go to the video directly by clicking: X-Code and OpenGL Tutorial Screencast.
Note: The replacement include statements I list in the screencast are actually a bit more than necessary – you can use these shorter ones instead (be careful: those are two underscores on each side of the word APPLE):
Where you see:
and where you see this (in later assignments only):
Why? GLUT (glut.h) includes gl.h, and GLUI (glui.h) includes glut.h, thus you only need the “highest level” of abstraction and utility around the core OpenGL explicitly included.
If you get an error regarding tchar.h when compiling the sample apps, that’s just because TCHAR is a Windows-only macro that turns into the correct kind of char for a particular build. You’ll just want to use regular “char” and “int main” when making your own app, but to avoid modifying the sample apps too much, you can just download this tchar.h file and add it to the X-Code project. (It just makes the substitution for you at compile time.)
Remember: The professor will still be using the Makefile (example provided in 557_Support_Files.zip) to re-compile your application, so make sure you update the Makefile and test it before submitting. You’ll want to submit your cpp and h files, your Makefile, and a binary – best to include the one made by the Makefile, but if you want to find your X-Code one (for testing or another purpose) it’s in the build directory inside your project directory, in the Debug or Release folder (depending on your build configuration chosen in the main X-Code project view).
Feel free to click on this post title (to view it on its own) and bookmark that page for your own use.