Total migration from GLC to GLCS

[ZDBioHazard]

In issue #4, @lano1106 mentioned wanting to move toward renaming everything from GLC to GLCS, and mentioned something about going crazy, which got me thinking. :wink:

Just for the sake of my curiosity, I ran a bit of sed over the codebase, converting everything which hasn't already been converted to GLCS, everywhere.

grep --exclude-dir=.git -lre '\(glc\)\([^s]\|$\)' | xargs sed -i 's/\(glc\)\([^s]\|$\)/glcs\2/g'
grep --exclude-dir=.git -lre '\(GLC\)\([^S]\|$\)' | xargs sed -i 's/\(GLC\)\([^S]\|$\)/GLCS\2/g'
git mv src/glc{,s}
git mv src/glcs/common/glc{,s}.h
git mv scripts/glc{,s}-build.sh
echo "$(git diff -U0 | grep '^+[^+]' | wc -l) changed lines."

(If you try running that for yourself, please make a backup of your .git directory first, just in case --exclude-dir doesn't work for some reason)

To my surprise, everything compiles and recording/playback seems to work fine. It doesn't even create any new compiler warnings. Cool.

Changing everything affects about 2,400 lines (13,000 lines of -U3 diff), which would need to be looked over so things like comments or copyright notices in reference to the original GLC could be fixed. I wouldn't mind spending the time to go though it if you're interested.

Note: The GLCS_SIGNATURE value is not changed from 0x00434c47, so *.glc files still use the same format, though new files would be created with the *.glcs extension, which of course can be easily be reverted.

[lano1106]

wow. that is scary but cool at the same time.

You are correct. some comments and copyright notices have glc reference that needs to be preserved in order to respect the original glc author license.

If you want to do it, I'm sure interested to it and will review the result to merge it back.

cheers!

[ZDBioHazard]

Heh, I got sidetracked on another project for a few days, but I had a few hours to go through this massive diff, and I ran into a problem at the end: This patch is absolutely massive. In addition, because it involves renaming a large directory, the pull request would just be a bunch of opaque whole file deletions/additions, and nobody would want to review that.

I could do all the edits in one commit, and rename the files in another, but that will result in the first commit not compiling if someone checks it out, and I don't know what this repository's rules are about non-building revisions.

[lano1106]

Hi Ryan, the repository rules are a bit informal. Since so far, it is only you and me, I do not mind to agree to anything that sounds reasonable.

Of course, I would prefer to keep the master compilable if possible.

How about 2 commits in the same pull request? Would not that work? Someone could review code changes from the first commit and proceed to the renaming in the second commit.