Recursively Packing Source Code Into One File? - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: Recursively Packing Source Code Into One File? (/thread-382.html)
Pages: 1 2
Recursively Packing Source Code Into One File? - daveh84 - Jan 30, 2010 10:04 AM
I want to pack all my source code into one file and print it out before releasing my software for archiving purposes. I have over 150 source files, so doing this manually is unrealistic. I feel like there should be some way to do this in a single UNIX command, possibly "more" or "cat" or something, involving a pipe, or > operator, and *.m, *.c, *.h...
If anyone can help, I'd greatly appreciate it... And I feel like this is something we could all use, if only for fun to see the true magnitude of our work.
Recursively Packing Source Code Into One File? - daveh84 - Jan 30, 2010 10:10 AM
I found out all my source files were in 1 directory... The nested directories were only virtual directories in Xcode. So the solution was very easy, and in case anyone's curious, here's the command I used:
Recursively Packing Source Code Into One File? - Skorche - Jan 30, 2010 12:01 PM
I don't think that's what you really wanted. If you want to make a backup of the files and folder structures you should use the tar command. Even simpler, just use the Finder to make a .zip for you.
Now, what you really (really) want is version control. Something like Subversion where you can see what changes you made to your source code as you created the program and can create snapshots at different times and have it generate lists of differences for you. Subversion has a simple learning curve to it too.
Recursively Packing Source Code Into One File? - SethWillits - Jan 30, 2010 02:17 PM
Think of the trees!!
Recursively Packing Source Code Into One File? - cmiller - Feb 1, 2010 01:12 PM
Skorche Wrote:I don't think that's what you really wanted. If you want to make a backup of the files and folder structures you should use the tar command. Even simpler, just use the Finder to make a .zip for you.
Use git. You can have the whole darn repository local to the directory your project is in. With Subversion you'll have in make a repository location either on a server or on your drive, then check out a working copy somewhere different. How stupid is that? With git, the repository and the working copy can be in the same place. Much easier to work with.
Additionally, Git is much better at doing complex things like adding more than one file at a time, ignoring files you don't want to put under version control, and even super-crazy things like branching.
I just download the sources for the latest release and then ./configure --prefix=/home/cmiller/.bin/git; make; make install it. It's much easier that way for me.
Overall git is faster and more robust. The only reasons I can think of for not using Git (or Hg, or Darcs, or any other modern SCM) is that you either don't want to learn or have an existing system that is too difficult to migrate. Otherwise? Go for it. It'll pay dividends later on.
Recursively Packing Source Code Into One File? - OneSadCookie - Feb 1, 2010 02:08 PM
This is the easiest way to install git on Mac OS X: http://code.google.com/p/git-osx-installer/
Both git and Subversion can easily operate completely locally, but you lose the benefit of having an off-machine backup if you choose to do so.
Recursively Packing Source Code Into One File? - Kerome - Feb 2, 2010 01:25 AM
Alternatively you could just go with a batch file to construct a temporary directory with just source and project files, and then use something like 7zip's command line version to create an archive out of it in a location of your choice (I use an external hard drive myself).
Local source control is still a good idea though, just for those rare cases where you embark on a line of experiments which don't work out and want to roll back a few files. Personally I find a local Subversion repository easy to use, though if you're going to evolve the project to a larger team Git or Mercurial might be worth a look.
Btw, Subversion's branching mechanism is good and very capable. The only problem it has is that it's a client-server system, so you bottleneck on server performance with larger distributed teams.
Recursively Packing Source Code Into One File? - cmiller - Feb 3, 2010 01:18 PM
Kerome Wrote:Btw, Subversion's branching mechanism is good and very capable.
Subversion's branching is fine conceptually, but the merging is a hellish nightmare. Coercing it into simply creating diffs between the two sources takes much work. Then you have to either use a caveman editor like vi or nano to edit raw inline diffs, or else worse. By worse I mean finding every file.c.branch and every file.c.trunk and using your merge tool to merge them into file.c itself. Now, delete both file.c.*, then use Subversion's braindead resolve tool to tell it that you have merged the two files. If you have a small project, this usually isn't too bad. As soon as you get above 15 files it's officially a pain in the rear. May God help you if one of those files is machine-generated (such as an Xcode project file, if you're doing iPhone work). I personally don't think I should be required to read and understand that big mess of XML. If you every try merging two Xcode projects, you will need to both read and understand that big mess of XML.
Once it took myself and two other engineers four hours to fix a failed Subversion merge, complicated by the fact that Subversion had somehow committed a .svn file to the repository. Unless you want to become a Shaman of the angry Pantheon of Subversion merge Gods, do not, do not, do not, do NOT ever branch anything in Subversion. It's not simple. It's not quick. It's not easy. You will end up reading and memorizing at least four manpages. And if you're doing that, you're not working on what you're supposed to be working on.
Furthermore, most GUI tools for OS X for Subversion either don't have branching or they simply don't have merging support. When we spent four hours fixing it, we ended up using an old PC (mine) and TortoiseSVN because the merge command we were using locally was either poorly explained such that three engineers could not understand it, or the documentation was completely wrong to begin with.
Save your sanity, use Git. Or Mercurial, or Bazaar, or whatever. Use freaking RCS, but don't use Subversion.
Recursively Packing Source Code Into One File? - Skorche - Feb 3, 2010 02:13 PM
Uh... Ok... I've don a lot of Subversion branching and merging and have rarely ever had anything that turned out to be difficult. How is "coercing" it to generate diffs hard, I do that on a daily basis. You basically just say svn diff branch_a branch_b.
When you get conflicts in something like an XCode project, how is it supposed to be pleasant to merge them? Maybe I'm just a VC nOOb, but I don't really see how any fancier algorithms, tools or visual diff editor can help me here.
Recursively Packing Source Code Into One File? - ThemsAllTook - Feb 3, 2010 02:19 PM
I've done quite a few branches and merges in subversion, and when done properly, it's usually completely painless:
Recursively Packing Source Code Into One File? - cmiller - Feb 3, 2010 02:33 PM
Obviously we weren't doing it right, but the fact still stands: unless you're lucky, or you have someone on hand who knows what they're doing, it can get really crazy really fast.
In my experience, Git is just a more robust, more friendly version control. I don't know all about Git or Subversion, but from my chair, git > svn.
FWIW, both will work fine, but I'd strongly suggest Git.
Recursively Packing Source Code Into One File? - Kerome - Feb 3, 2010 02:36 PM
Or you could use this standalone industrial-strength merge tool, which is free and runs on OSX...
Ideally you'd write something like a python script around it in order to do a series of invocations, and sort out the surrounding svn commands to tell it that you've resolved the errors. But I suppose that depends how often you're going to need it, which hopefully would not be too often.
And maybe I should point out that Perforce's 2-client license is free as well, for those who want to pursue a career in games - right now it's industry standard tech in at a lot of high-end games developers, and experience with it will be a definite plus point for cv's. Although I have to say that Git and Mercurial are starting to gain some traction with startups, and I've seen a few using Subversion as well.
Recursively Packing Source Code Into One File? - Skorche - Feb 3, 2010 03:32 PM
I guess I still prefer the simplicity of Subversion. I haven't used Git extensively, but it seems like there are maybe double the number of commands and options that I need to memorize to do my day to day work. The added complexity doesn't really seem to buy me anything other than local commits.
And I would very much agree with ThemsAllTook that if you end up with giant merge conflicts, then you are waiting too long to merge. If you are working on a branch that will exist for a long time, you should occasionally recreate the branch from trunk and merge in your changes. That way you are getting trunk bugfixes as well as avoiding a giant integration later when two different people have heavily edited the same parts of a file over a long period of time. From what I've seen, this is the same thing that Git encourages by having you pull other peoples' changes into your branches regularly.
I wonder if we've basically scared the OP off by now...
Recursively Packing Source Code Into One File? - ThemsAllTook - Feb 3, 2010 04:44 PM
Skorche Wrote:I wonder if we've basically scared the OP off by now...
It looks like he solved his own problem, and had no reason to pay attention to the rest of our chatter that had little to do with him.
Recursively Packing Source Code Into One File? - Kerome - Feb 3, 2010 05:53 PM
We could start discussing unity builds under the guise of the original thread title, if we wanted to further confuse things Go on, it makes a kind of sense...