Recursively Packing Source Code Into One File?

Member
Posts: 35
Joined: 2009.01
Post: #1
Hi,

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. Rasp
Quote this message in a reply
Member
Posts: 35
Joined: 2009.01
Post: #2
Hi,

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:

Code:
more *.h *.m *.c > archive.txt
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #3
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.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
⌘-R in Chief
Posts: 1,265
Joined: 2002.05
Post: #4
Think of the trees!!
Quote this message in a reply
Member
Posts: 144
Joined: 2009.11
Post: #5
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.

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.

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.

http://git-scm.com/

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.

Everyone's favourite forum lurker!
https://github.com/NSError
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #6
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.
Quote this message in a reply
Member
Posts: 26
Joined: 2010.01
Post: #7
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.
Quote this message in a reply
Member
Posts: 144
Joined: 2009.11
Post: #8
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.

Everyone's favourite forum lurker!
https://github.com/NSError
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #9
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.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 1,562
Joined: 2003.10
Post: #10
I've done quite a few branches and merges in subversion, and when done properly, it's usually completely painless:
  • Perform a clean checkout of the source you'll be merging to (probably trunk).
  • svn merge http://repo/branch@REV http://repo/trunk@HEAD . (where REV is the revision at which the branch was created; can be easily determined with svn log)
  • Make a note of any files marked as conflicted, and resolve them manually (rarely if ever as painful as people complain it is, and if it's a lot of files, you're waiting too long to merge)
  • Commit
Easy as pie.
Quote this message in a reply
Member
Posts: 144
Joined: 2009.11
Post: #11
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.

Everyone's favourite forum lurker!
https://github.com/NSError
Quote this message in a reply
Member
Posts: 26
Joined: 2010.01
Post: #12
Or you could use this standalone industrial-strength merge tool, which is free and runs on OSX...

http://www.perforce.com/perforce/products/merge.html

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.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #13
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...

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 1,562
Joined: 2003.10
Post: #14
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. Smile
Quote this message in a reply
Member
Posts: 26
Joined: 2010.01
Post: #15
We could start discussing unity builds under the guise of the original thread title, if we wanted to further confuse things Wink Go on, it makes a kind of sense...
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Some Game / Engine Source code in C++ and MSVC kiavash2k 1 5,392 Apr 12, 2012 11:35 PM
Last Post: DJyStyler
  Source Code Nick 9 6,004 Jul 17, 2004 11:02 PM
Last Post: Josh
  3dfx video card drivers source code released! xDexx 4 3,285 Jun 6, 2003 12:32 PM
Last Post: wadesworld
  File Code Problems Muffinking 16 6,755 Jun 17, 2002 06:54 PM
Last Post: WFleming
  Carbon File Code Muffinking 5 5,154 Jun 3, 2002 12:23 AM
Last Post: henryj