Should I add *.pch files to .gitignore in XCode projects?
No, you should not. It's not a generated file, you as a developer may (and should) modify it. The point is to put the most commonly used #import/#include directives in here. That will speed up compiling as Xcode will then precompile it and GCC will use these "cached" results when compiling other files without the need to parse and compile those includes over and over again.
I found the speedup to be especially dramatic with C++, BTW.
To add a bit more context to the question - What files should you consider ignoring in a VCS?
Personal settings files such as *.pbxuser. These are things that contain the settings for your personal environment or workspace. Not much use to anyone who clones the repository and of marginal use if you are using a repository across machines
Generated files. If your project generates files then there is no point in having them in your repository because unless you are always generating them, they end up out of date. This is why you frequently see build/ in the .gitignore file
Files that contain passwords or access tokens. Pretty obvious, really.
Put it simply. Don't ignore anything that your project requires to build. The PCH file is referenced in your project settings and you'll get a build error if it doesn't exist in the project so it really should be in the repository.
No, they're important to the project.
They're prefix headers and will be imported to every file within the project.
I don't use git, I use svn but the ignore settings should be the same. When I set up a project, the only things I ignore by default are:
the build directory
*.pbxuser and *.mode1v3 in the xcodeproj bundle.
Everything else (including the pch file) is something that should be under source code control (unless you add other generated files outside of build).
Related
I've been working on a public Visual Studio project in GitHub, and have been uploading the entire solution folder into the repository, with all files. Are there specific files or folders that I should refrain from uploading to my repository? I've heard that certain folders can contain cache or user information, but I'm still not sure what to remove.
I always generate my .gitignore file with this website.
If you are working on an ASP .Net project and have connectionstrings for a DB in your appsettings, never push this to github. Best is to generate a appsettings.example.json and only have the structure and propably some default values in there.
Broadly speaking, you should not upload on github following:
any content which does not legally belong to you, and which has no some open source license.
content which could be generated (e.g. object files).
Specifically in your case
You can put source files in the repo but not things generated from the source.
Also, you should not commit class files. You should commit your build scripts, but not files generated by the build.
Lastly keep in mind the size limitations of 100MB per file.
Read also Hello World · GitHub Guides (https://guides.github.com/activities/hello-world/#what)
You can use the .gitignore file to ignore the IDE's config and build cache and the .env files. In particular, it is useful to write .env file to .gitignore to avoid some credential leaks caused by hard coding.
GitHub and the community provide common .gitignore rules, see https://github.com/github/gitignore.
Example:
# Generated by Cargo
# will have compiled files and executables
debug/
target/
# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
Cargo.lock
# These are backup files generated by rustfmt
**/*.rs.bk
# MSVC Windows builds of rustc generate these, which store debugging information
*.pdb
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).
I am building a cross platform product and one of the requirements is across windows(win32,AMD64 and IA61). The product as is relatively simple CLI but we have a separate build team who checks out the code from CVS and build in separate build environments. I am able to build succesfully(using Visual C++ 2005) in one platform(AMD machine). But once I check in the code, check out the build fails.
The cause of the build failure is because the include library paths are wrongly specified in the property sheets. Specifically the output file folder under the Linker in property pages are specified wrongly. So these libraries get built in a different folder from where the other projects are expecting them.
However along with the source I check in the .sln files (and later .vcproj files) also everytime. Morover if I open the .sln file in the folder where the build is not succeeding, there is no difference between the one where I could succesfully build(pre check in). In fact using windiff I could not see any difference between the two build folders (except some .ncb and cvs log files).
So any idea what is going on? Where does VC++ 2005 take the include directories take the output folder path from if not from .sln? Is CVS somehow interfering with the process? Anything else I could try out.
Thanks in advance.
Just to update the problem was resolved. The root cause is the .vcproj files were not getting checked in CVS!! This is where the individual project settings were stored(I was under the impression that this is done in .sln files).
I think the problem can be that after you have changed the settings in one build configuration (for example x86-Release) but forgotten to change them for another configuration (for example ia64-Debug), and when configuration changes, you have this problem.
Another thing that I would check on your place is project dependencies. If those are set in the right way VS will look for project output exactly where it is outputted, even when you change the output folder.
Do you have any binary files checked in as ASCII?
The round trip to and from CVS can corrupt binary files that are incorrectly marked as ASCII because CVS performs character processing on ASCII files (e.g. to give you the correct end of line codes for your OS). Corruption can occur even in an all Windows environment.
See the Binary section in the CVS FAQ for more information.
I am trying to set up Xcode for a project which contains multiple executables and static libraries. I have created multiple targets and set up the linking and dependencies, and initially everything works great. The catch...
This is an existing project which already has Visual Studio and Makefile builds. Those builds put the libraries in a lib/Debug directory and the executables in bin/Debug. So in Xcode I changed the Build Products Path to "lib" and "bin" respectively (so we can use one set of documentation for all of the platforms). This puts the compiled targets in the right place, but completely breaks both the linking (Library not found) and the dependencies.
I can fix the linking by adding $(SRCROOT)/lib/Debug to the Library Search Paths for each executable (but it feels like Xcode should be able to figure this out on its own, which makes me think I'm doing something wrong).
But — I can't figure out how to get the dependencies working again. If I change a library source file, the library will rebuild but not the dependent executables. If I force a build of the executable Xcode returns success without doing anything; it thinks the target is up to date. If I clean the target and then rebuild it works.
So, any ideas here? Is Xcode being fundamentally stupid in this regard, or is it me (I'm leaning toward the latter)?
Update: I've posted a sample project to demonstrate the issue at http://share.industriousone.com/XcodeDepsIssue.zip. Build it once, then modify MyStaticLib.c and build it again. The executable will not relink (and it should). Many thanks for any help on this one.
starkos, thanks for publishing your conclusion. It validated my experience as well. This situation really screwed me, so it was nice to know I wasn't just missing something.
I did however discover a workaround that avoids creating multiple projects or keeping the library and its dependent in the same directory. It is a hack, but it does work here.
I know it's a bit late but better than never.
For the dependency library, add a "Copy Files Build Phase", with Absolute Path as the destination, and the path text field should be the directory where the DEPENDENT target lives. Then click on Products, find the dependency library (will end with .a), and drag it into the "Copy Files Build Phase." If you now build, this will put the library into its own directory like before and THEN also copy it into the dependent's target directory.
For the dependent, you can now remove the dependency's output directory from the Library Search Paths. This will cause it to find the library copy. If you do this, the dependent will indeed be relinked each time the dependency .a is relinked.
The negatives are, of course, the extra time for the copy, and the necessity to specify (in the Copy phase) the target directory for each dependent of your library. Beats the hell out of the alternatives though....
Xcode doesn't automatically set up dependencies based on use of build products; you have to set up explicit target dependencies yourself.
Project > Edit Target Settings, General tab, + button, add any targets that are prerequisites to building the selected target. That should get you going again.
I've researched this some more and the answer is no, Xcode 3.x doesn't track dependencies between targets that live in different directories. You can work around it by giving each library its own project, and adding each of those to a master project. Or you can keep all of your targets in one directory. Pick your poison.
Here is my solution for this weird behavior in xcode 4.3.1. You have to add build pre-action in scheme:
rm -f ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
and choose which build settings to use for this script. Each time before build, target executable will be removed and rebuild completely. It helped for me, and i hope it helps you.
NOTE: Have tried to put this script in project build phase, and result was negative - debugger could not connect process to start debugging.
Good luck!
OK, it would help to have the text of the Linking... build line that's failing. But a couple of things:
1) You shouldn't be linking to anything in $(SRCROOT). That's your project sources. The two places to find things to link are $(SYMROOT) (the Build Products directory) or $(DSTROOT) (the Installed Products directory).
One thing you could do is to have a common Build Directory, then use 'xcodebuild install' action to install the products in the Installation Directory. The other is to use a Copy Files build phase to copy them after building, so you can link against them in $(SYMROOT) but still have them where your Windows compatriots expect them.
THere is probably a way to set up the per-target build products directories correctly, but I'd really have to see the project itself to figure it out.
I just started working on my first Visual Studio project, and I imported all the existing code for the project into an SVN repo of mine without checking which files were binary and which weren't. So now I'm trying to clean up the repo and I've come across some .sbr, .pch, and .res files.
I figure the .pch file doesn't need to be in source control because it's binary. But the sbr and res files are currently empty, so I can't tell offhand if they should be in the repo. So should they be in or out?
.res files are compiled versions of .rc files, so they don't need to be in the repository either.
After removing all the files you don't believe are necessary (most non-text files except images are probably not necessary), you should check out your project into a clean directory and attempt to do a full build. If it fails, then you removed too much. (If it succeeds, then you may be able to remove more stuff!)
They should not be in the repo. They are all intermediate files created during compilation.
Res may be necessary since they can contain resources. SBR is source browser and should be created on compile if you're using the /Fr option (I think).
Edit: Never mind, I assume the poster above me is correct. Make sure you have the .rc/rc2 files then.
.pch files are pre-complied headers and do not need to be included in SVN. They will be recreated when you check out your codebase and and do a build.