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.
Related
I have just finished my C# Windows form program and would like to make a zip file of the binary so others can download it. I checked the bin/release folder, and while I can recognize many files which I know will be necessary, but some other files I am not sure if it is safe to exclude them.
The following files are the ones I am not so sure:
program.pdb
program.exe.manifest
program.exe.config
program.application
ExternalDLL.xml (related to
ExternalDLL.dll which I need to keep,
but is the xml important?)
P.S. I am using VS Express so I have to manually deploy my project.
The short answer is: You don't need any of those, with the possible exception of the .config file. If you didn't store any of the app's configuration in its .config file, then you don't need it either. I recommend excluding all of them and trying your app on a different machine. I expect it'll work fine.
The longer answer is: There's probably individual SO questions about each. For example, here's a manifest/application question: C# - do I need manifest files?
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).
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 would like two things:
to be able to change branches in git, and then Run or Build in Xcode without recompiling the entire project.
have git ignore intermediate build files during merge, so it won't ask me to resolve any conflicts.
Putting the intermediate builds folder outside the project, or using .gitignore to ignore that folder, accomplishes #2 but not #1; I have to rebuild the entire project when I change branches, even if I did not modify any files.
Well, you've answered #2 correctly yourself, so really your question only related to #1. I don't really see why Xcode would need to recompile things either - git won't change timestamp on unchanged files when switching branches.
Have you actually implemented the #2 solution, so that the entire problem isn't caused by git stomping on your build directory, which should be .gitignore'd?
You could define two variables:
MY_BRANCH_NAME = branch_foo (adapted in each branch)
TARGET_TEMP_DIR = $(CONFIGURATION_TEMP_DIR)/$(TARGET_NAME)$(MY_BRANCH_NAME).build (the same for all branches)
This way, the builds for your different branches will be made and keeped in separate folders, not needing to recompile everything because of a branch-to-branch config change.
You can do it in xcconfig files, or automatically define MY_BRANCH_NAME as an xcodebuild argument in a build script, among other means.
Xcode is going to do all of its data based on the timestamps of the files in question. If you replace the file with a newer file, then Xcode should notice that the timestamp of the file is newer than the timestamp of the build product and recompile it.
However, if you change it with an even older version of the source file, then it can't know that the build file isn't correct. It will just see that the build output is still newer than the source file, and so not recompile it.
In short, you can't know which files have definitely changed, and which have definitely not. You're better off doing a full clean+rebuild to make sure; otherwise you're going to lose time debugging when it doesn't work.
What are the *.FileListAbsolute.txt files for that Visual Studio generates? They keep cluttering up my searches. Such as when I search for *.csproj for adding projects to a .sln.
Does Visual Studio use them? Is there any way to make it not generate them?
The FileListAbsolute.txt file contains the list of files built in the current build and in prior builds, and is used during a Clean and Rebuild to figure out which files to delete.
The file is necessary because in certain situations, such as a project that has been renamed, you want the Build system to be able to delete the older name.
I know this is an older post...but I had this same issue and it turned out that I had accidently checked these into source control and not checked them back out, leaving them read only. The solution was to remove them from source control.
It tracks files to be deleted upon clean. From Understanding the Clean target:
[T]he common targets implement an honor-system method of tracking the output of "the last build". Well-behaved targets emit their outputs into an item named #(FileWrites), which is serialized to $(CleanFile) in the obj directory (it ends with .FileListAbsolute.txt) in a target named _CleanRecordFileWrites. Clean can then read that list and delete files in it during a subsequent MSBuild invocation.
Im not sure why it's generated and am researching that now. VS writes to these files each time you compile. You can delete all of them and it will regenerate when you compile. (Use caution if you use svn and don't delete the svnbase files)