macOS Xcode and Git Projects

[s4yunkim]

I mostly do my C/C++ programming on the command line (Vim, Gdb, Valgrind, etc.), but since having used IDEs for other languages (like IntelliJ for Java, etc.), I wanted to get started using Xcode on my MacBook for developing in C/C++.

My issue is this:

• Generally, I have a GitHub/GitLab repo setup with my source files, makefiles, etc at the root of the repo. (e.g. reponame / main.cpp)
• When I set up a new "project" with Xcode, and use Xcode's git integration to push files to GitHub, it places them in two nested folders. (e.g. reponame / Xcode_Project_name / Xcode_Project_name / main.cpp)

Not only does this look odd, it's confusing for friends who are pulling the code to take a look, but are not on a Mac (the project may be cross-platform, and they are on Linux).

So I tried this:

• Create the main.cpp, etc files on the command line, and push to the git repo, so that the repo is organized with the source files at the base. (e.g. reponame / main.cpp )
• Then use Xcode's source control features to clone a repo.

This apparently just pulls the repo, places them at the root of the folder I select, and does not provide any sort of "context" (*.xcodeproj, etc). Xcode acts as if it has no idea what these files are, and acts as a simple text editor.


Is there a way to "import" a preexisting repository (that isn't set up for Xcode) into an Xcode project, so that I can use Xcode's tools and editor to work on it? (This would be a preferred solution)

-- or --

Is there a way to create a project in Xcode, but have it maintain the code in a folder outside of the nested structure that it seems to want to put them in?



Many thanks in advance!

 

[jtara]

Caveat: I never use XCode GUI (just build from command line) and so I don't use XCode Git support.

(I write hybrid mobile apps use the Rhodes platform, and I manage git with the excellent Tower GUI tool).

I'd guess XCode wants the PARENT directory of your new repo, not the repo directory. If you look at it in that context, the directory structure makes sense.

Create a repo directory called {Xcode_Project_name} and then another directory inside of that with same name. (Does it give you any options?)

It would be common to have other directories that are not built e.g. /doc, and so that accounts for the two levels. (I put my app in a subdirectory called mobile_app, and then have /doc, /artwork (for original artwork, .ai, etc.), and so forth.

Where does it put the .git directory?

 

[s4yunkim]

If the Xcode generated structure is:

[Root Folder]
./git/
./projectname/
./projectname/main.cpp
./projectname.xcodeproj

So when it gets connected to remote repo, it gets uploaded such that the first thing visible is the "project name" folder.

Ideally, I would like like the fact that I'm working on this code in Xcode to be invisible to anyone who looks at this repo online. For example, if I wrote a simple "Hello world" program, I would like anyone who clones the repo (be it on Windows, Mac, Linux), to get the .h and .cpp files, independent of the files my IDE wants to put around it.



Similarly, if I jump on another Mac and clone this source code (or any other, for that matter), I'd want to be able to pull it into Xcode and continue work on it there... is that even possible? Does Xcode have an "import into project" function that I'm just not seeing?

 

[BugHunter]

I would very strongly recommend you checkin the XCode files as there's a lot of configuration in there, even if you're not that keen on exposing it. Even what files get compiled in are typically referenced in the workspace/project files even if they're in the same directory as everything else.
So there's no real "import project" as everything is contained in those files.

As a general rule I never use XCode for git (except to see what files have been modified or added). I'll always fall back to a third party tool like SourceTree to do all merging, pushing etc. So I'd just recommend manually configuring the directory at whatever depth you'd prefer.

 

[jtara]

I concur with the above. You should be checking-in your XCode project files!

On the other hand, anything that is machine-generated, or (in most cases) is developer-specific preferences should not be checked-in.

From my .gitignore, these are the XCode files I do NOT check in:

#-------
# XCode
#-------
xcworkspace/
xcworkspace/*

# user-specific
xcuserdata
xcuserdata/*
.xcworkspace
*.xccheckout

contents.xcworkspacedata

 

[s4yunkim]

Thank you for all the insights. It's seeming more and more like there isn't really a way to keep a repo "IDE-neutral" while being able to work on it with an IDE of choice when pulled. Not cleanly anyway...

I suppose I will put everything in an Xcode project, since I'll be the main contributor, and make a small Makefile that will make it a one-step command to compile and run on Linux or something.



That does beg the question, however: How do problems like this get solved in practice?

Obviously, not all C/C++ projects are developed in a single way, so someone who writes everything using... say... Visual Studio is going to run up against something where they will have to "adapt" a project someone else wrote into their build environment (project originally written in Xcode, but I run Windows so I want to work on it with Visual Studio, etc).

Is there no sort of standard for this? (For platform agnostic programs, that is.)




(Some background): In my university program, we were taught to do C/C++ for the first year in a text editor and using command line tools, no IDEs allowed. This was great for cementing C/C++ skills in the formative years, but IDEs exist for a reason, right? My first experience with an IDE was Webstorm, while taking a web development class. It was nice that I didn't have to worry about how the original code my professor gave us was developed, I could just open it in Webstorm and work on it.

Now I come back to C/C++, hoping to get familiar with an IDE, and write a project that my friends on Windows and Linux can also contribute to..... and I run into the mess that we've been discussing above....

 

[Krevnik]

The mess isn't just at the IDE level, it is all the way down. And you will have to tackle it for a cross-platform project.

Toolchains are not identical across platforms. You can't assume Apple's clang is configured the same way as 'stock' clang on Linux, or MSVC on Windows. It's easy in C++ to wander into undefined parts of the spec where one compiler will accept it and others won't. You can't assume the core APIs are all there either. Historically, Windows never supported the POSIX APIs despite having a few like WINSOCK that are heavily based on their POSIX counterpart, for example.

When it comes to build environments though, usually I would recommend something akin to cmake & autoconfigure. You can include an XCode project that builds the cmake project on Mac platforms to provide access to an IDE, while still using the same process to build as the command-line. But in general, IDEs and cross-platform build environments tend not to mix.

That said, it's been ages since I've worked at that layer in the OSS world. I honestly don't know what cross-platform build chains folks are using these days with new projects, but I'd start there. The project I work on these days has its own build environment and we do support a number of platforms with it. And yes, it is a bit of a mess.

EDIT: Brian from Backblaze has some interesting things to chew on when it comes to this sort of stuff: https://www.backblaze.com/blog/10-rules-for-how-to-write-cross-platform-code/