I have an online repository with some .h and .cpp files that make up part of a project. I'm trying to check these out and use them in a new project, but am getting errors (C4627 and C1010). All the files have been added to the project (with Add>Existing Item...), and the subdirectories that contain these files have been added to the "Additional include directories" of the project.
Would I be better off having the entire project tree in the repository? My reason for not doing so is that my colleague and I are working on different parts of the code and so want to use different main methods to test things as we go, and I didn't see any need to be passing around any compiled code etc. since I assumed that given the .h and .cpp files (with the correct settings), visual studio would be able to compile the project.
What's the best way to make Visual Studio 2008 and TortoiseSVN work well together (without spending any money)?
Would I be better off having the entire project tree in the repository?
Most certainly yes. You should be able to check out and build without much effort. Creating a new project every time you want to build the source and having to configure it is way too much work.
My reason for not doing so is that my colleague and I are working on different parts of the code and so want to use different main methods to test things as we go, and I didn't see any need to be passing around any compiled code etc.
Ok, just put more than one project in the solution. There's no reason you can't have separate executable projects for separate tests.
I assumed that given the .h and .cpp files (with the correct settings), visual studio would be able to compile the project.
If all of the settings are the same, then, yes, it should compile fine, but why bother with the hassle when you don't have to?
Also AnkhSVN which isn't too bad and it's free. Also, lots of the windows it displays look like TFS (if you're familiar with it)
What's the best way to make Visual Studio 2008 and TortoiseSVN work well together (without spending any money)?
There are a bunch of programs that integrate SVN into Visual Studio. VisualSVN is one of them.
Apologies for the VisualSVN recommendation. We used to use it in an old project and I'm positive it was free then. Maybe they changed their license?
Related
I am working on a huge C++ project, targeting many platforms with several configurations for each platform.
Because of the long compilation time, build the entire project on every platform to test if a change compile successfully, isn't an option.
What I usually do, is compile the single cpp modules I modified on different combination of platform/configuration.
I'd like to automate this process, either using a script, a VS extension, whatever, I am open to evaluate different options.
What I need exactly is taking a list of cpp files and compile each file, for each platform and each configuration (basically iterating through all combination of the configuration manager).
Is this possible? any good suggestion on how to approach the problem?
EDIT:
I am aware that this is way far to be a perfect solution, and will spot only a subset of errors.
I will still have to face linking errors, compiler errors on other cpp units depended on a modified header, and so on..
I also, don't have any chance to modify the current build system, or project generation.
I am mostly interested in a local solution, to reduce the amount of possible issues and facing the huge building time process.
EDIT2
We have a build system. This has to be considered a pre-build system optimization, for my personal workflow.
Reasons:
Triggering a build system job requires time. It will be the final step, but instead of spending hours waiting, and maybe discover later that a given compiler on a given platform for a specific configuration raise an error, it would be much more efficient to anticipate those findings as much as possible.
Current manual workflow:
Open each cpp file I modified
Compile each cpp file as a single unit (not building the project. On VS Build-> Compile)
Change Platform and/or configuration and re-do point 2 again.
This is the manual workflow I'd like to optimize.
I would suggest that you "simply" write a script to do this (using Python for instance, which is very powerful for this kind of this)
You could:
Parse the .sln file to extract the list of configurations, platforms ( GlobalSection(SolutionConfigurationPlatforms) entry) and projects (Project entry)
If needed, you can parse every project to find the list of source files (that's easier than parsing the .sln, as vcxproj files are in xml). Look for ClCompile xml nodes to extract the list of .cpp files.
Then you can identify which projects needs some files to be recompiled (getting list of modified files as script input parameter or based on timestamp checking)
Finally, to rebuild, you have two options:
Call "msbuild " to recompile the whole project (vcxproj) (for instance msbuild project.vcxproj /p:Configuration=Debug;TargetFrameworkVersion=v3.5)
You could also recompile a single file (cl simple.cpp). To do so, you need to know what are the cl build options to be sure you compile the file exactly the same way as Visual Studio would. If you earlier did a full build of the solution (it could be a rquirement for your script to work), then you should be able to find that from Visual Studio logs (within the target folder). In my solutions, I can find for every project (vcxproj file) a build log per configuration (in %OUTPUT_DIR%\lib\%libname%\%libname%.dir\%configuration%\%libname%.tlog\CL.command.1.tlog), this file reports the exact cl arguments that were used to compile every file of the project. Then you can manually invoke cl command and this should end up recompiling the file the same way Visual Studio would do it.
Additionnaly, you could add a project in your Visual Studio solution that would fire this script as a custom command.
Such a script should be able to identify which projects has to be rebuilt and rebuild them.
This is a very common requirement, it is never solved this way. What you are proposing is not completely impossible, but it is certainly very painful to implement. You are overlooking what should happen when you modify a .h file, that can force a bunch of .cpp files to be recompiled. And you are not considering linker errors. While you'll have a shot at discovering .cpp files, discovering #include file dependencies is very gritty. You can't get them from the project or make file. Compiling with /showIncludes and parsing the build trace files is what it takes. Nothing off-the-shelf afaik.
Don't do this, you'll regret it. Use the solution that everybody uses: you need a build server. Preferably with a continuous integration feature so the server kicks-off the build for all target platforms as soon as you check-in a code change. Many to choose from, this Q+A talks about it.
I just decided to learn C++ and I installed Visual Studio 2012. My friend told me it's a monstrous program and I should avoid it, but it has one of the best compiler ever (advanced error messages, etc.) and i found it useful in studying.
The problem is there are option called Filter except for real Folders. Source code is organized in IDE but the project folder is just messy, everything is in the root.
I think it's good for the compiler - you can't be wrong while including files. But since u want to share your source files with your friends who don't use VS it's necessary to have files organized in folders.
Is there any option to export files into folders based on filers?
I do a fair amount of personal development on my computer and have used TortoiseSVN (I'm on windows) for web projects, but haven't used any version control for other languages. Anyways, soon I will be starting a decent sized C++ project and was going to try using SVN for it.
For web development, I normally just used notepad++ and it was really easy to manage it with SVN (just commit the whole source folder). However, for this project I will be using an IDE (most likely Eclipse CDT or Visual Studio) and was wondering what the best practice is to manage all of the IDE, project, and binary files. My guess was to make the IDE project outside of the version control, and just point to all of the source files into the SVN so all of the build and project files aren't committed. This way the only files in the SVN would be the .cpp and .h files.
However, if I wanted to switch to a new branch, then I would need to update the location of all of the source and headers to the new folder which seems like it would be a huge hassle.
Whats the best way to handle this?
Thanks
Ok, it seem I misgot the aim of the question in the first round. Now I'm assuming what is asked really to what to put under source control and what not.
Well, naturally everything but temporary/transient files.
If you install GitExtensions, it right away has a feature to populate the .gitignore file. Certainly depending on language you adjust it. Sure, solution, project, make files belong under control. .USER files storing some IDE preferences do not. As both IDEs and source control is ubiquitously used the content is fairly separated for many years, and should be pretty obvious as you do it.
External dependencies normally also shall be in a repo, though choice shall be made in which one. Some store everything together, others keep one dependency repo, others separate repos per component -- all depends on actual components and workflow. And you can replace physical storage of deps by an info file with stable links to the used version. It may also be covered later on the first change in dependencies.
For Visual Studio, there is a plugin that manages your files for you. As long as the files are part of the project, then they will be put into source control by the plugin. See ankhsvn for plugin info. Note that the express versions of Visual Studio are not supported.
I am sure eclipse has a plugin for SVN as well.
I have a big C++ solution in Visual Studio 2008 with many projects, that links to other libraries.
sometimes I want to link the solution to different libraries, and for doing so and create a new exe file I need to re-linking the solution.
But, the re-linking can be done only if at least one of projects need a rebuild. so I manually change one line in the code and change it back...
Is there a better way to only redo the linking process?
Isn't there an option in the context menü of the project? Only Project -> link only ?
Sorry I just translated it from my german dev studio 2008.
You could delete the exe. Thus it needs to be rebuilt which is a simple link.
Although if you use different libraries do you need different headers for them if so you need to delete objects - in this case probably best to dop a rebuild of the main project.
Probably the most complete alternative but most difficult to implement is to touch (ie change the modification timestamp) the library and headers you want to use and then Visual Studio build will do the minimum build.
In one Solution, I have two VC++ projects. Project A has linker inputs that are .obj files compiled by project B.
Visual Studio (2008) always tells me that project A is "out of date," and prompts me to ask if I want to rebuild it, every time I want to run/debug/build/etc. Even immediately after building the entire Solution: I do a successful full build, and then click Build again, and it wants to re-link Project A.
How can I prevent this from happening? Anyone understand what's going on here?
I think that the solution is to stop using .obj files from the other project. Instead, factor the code that is common to both A and B projects into own static library C and link both A and B to it.
I just had this problem with Visual Studio 2010 (both with and without SP1) and thanks to Ted Nugent I was able to fix it. The trick is to check whether all C++ header files listed in the project still exist, and remove the non-existing ones. Apparently this is a bug in the compiler.
Had something similar occur. I was working with code that used the system time and during the debug I was twiddling with it quite a lot. Somehow the files got some bad timestamps. In the build, it shows which files are getting recompiled, so I just opened each, forced a change (add space, delete a space) and then re-saved.
Similar to the old unix "touch".
In one project I had to do the same to its include files. But after 'touching' the files like that, the problem went away.