On May 18, 2017, at 10:05 PM, Quincey Morris < email@hidden> wrote:
On May 18, 2017, at 16:37 , Bryce Glover < email@hidden> wrote: What we (or at least I) think of as a “project” is a folder that contains the .xcodeproj package (the actual project), along with the root .git repository, plus whatever directories and files get put at that level. …
Hmm, that doesn’t exactly mesh with the mental model I tend to use for this kind of directory tree structure. I understand how you might have come to have this view of things, especially if you almost always work with Xcode projects stored inside Git repositories; but, personally, I like to at least try and keep whatever folder hierarchies I’m working with straight in my head. Calling both the Xcode project and the folder that contains it ‘projects’ is technically correct since an instance of the former is often stored alongside out-of-line files that it references in a way that it can share them with other build systems, but doing so could potentially encourage losing track of which level of the filesystem is for what purpose along the relevant path trail. I thus refer to the enclosing folder as the Git repository for the software project and the Xcode project for it as…well, an Xcode project, so as not to needlessly introduce new terminology, since that’s what it is (as I understand it, the `.git` folder inside any Git repository just stores repository metadata and objects, particularly those you aren’t currently using.) These kinds of mental gymnastics, of course, aren’t necessarily required when you aren’t working generically with respect to any possible Xcode project stored in a Git repository, as you can then just refer to the files and folders in question by name if you so choose instead of keeping yourself at the higher level of abstraction involved when dealing with an arbitrary number of arrangements involving Git and Xcode files. Functionally, however, it's (hopefully) obvious that the system this mental model describes is identical to the one your conception of it does. (Perhaps we’re simply in violent agreement here…? Just a random guess…) …This project folder can be renamed or moved anywhere in storage without disturbing anything going on inside it. …
The Git repository in which the Xcode project is stored, yes. …As a direct consequence, a duplicate of this folder is also a well-formed and well-behaved project folder.
Hurrah for reproducibility!
…
So you should store the base project folder somewhere, then just duplicate it when you want a new one. …
Right. …You don’t even need to rename anything inside the folder, if the project is just an exercise (which is what I think you said originally). …
Well, I’d like to be able to tell all of these exercises’ Xcode projects apart without having to inspect the names of their parent directories, … …Or, you can open the project in Xcode and go through the initial renaming process.
…
…so this is probably what I’d do.
…
It’s not even really necessary to have the base project itself be under source control. It’s pretty easy now to make a repository for an existing project, from within Xcode. …
Neat. …The only thing you really need to do is to fix the .gitignore file before you commit anything, since Xcode’s standard one is inadequate.
How so, exactly?
P. S.: Now that I think about it, maybe I’m getting myself all twisted into knots over nothing. The textbook’s supporting code eventually got supplied by an end user with a traditional Unix makefile, so perhaps I should just recreate that logic in CMake-ese and generate my Xcode projects using the resulting script.
|