I have a large VisualStudio solution with multiple projects.
So far it supports Debug|Win32, Debug|x64, Release|Win32, Release|x64, ReleaseLog|Win32, ReleaseLog|x64, (ReleaseLog is similar to Release but with logging turned on).
I'd like to add a new config type, similar to Release but only one compilation flag changes.
I'd like avoiding creating whole new section of Configuration in each vcxproj that are "duplicate" of Release configuration, and most importantly I want to be sure that beside this one compilation flag everything else will be exactly the same.
How can I achieve ?
Can we make a Configuration inheriting from another one ?
You need to inherit release through configuration manger -> new solution configuration and check create project configuration.
When I try to batch build my project, I encounter this error while I have enabled the clr runtime support.
My project can run with no problem and I only receive this error when I try to make a batch build.
I have made a lot of searched in google but most results are about enabling the clr option.
I'd like to know how I can fix this problem.
This is the kind of problem you'll run into when you make project setting changes while you are debugging your project. Settings are stored per configuration. A common mistake is to make the change for the Debug configuration but forgetting to make the same change for the Release configuration. Kaboom when you then try to get the Release configuration built, as would happen when you use Batch Build.
Go slower. Project + Properties, Configuration Properties, General. Note the combobox labeled "Configuration" in the upper left corner. It probably now says "Active (Debug)". Change it to "Release". And note how the "Common Language Runtime support" setting changes as you flip back and forth. Make them the same, /clr. Use Build + Configuration Manager to make the Release build the default configuration and use Build + Build to build it. Test it.
There might be other settings you've changed that need to be corrected for the Release build as well.
I'm trying to alter the default property sheet on a new install of Visual Studio 2010 for C++ projects. Just trying to add a few directories (for Boost etc.) and optimisation settings for release builds, basic stuff like that. Obviously there are some settings that I want to be different for different configurations. Problem is that whatever I try from the property manager window of my project, everything I do seems to affect both configurations.
I tried multi-selecting both -> right click -> properties initially, to set up common settings, and that did exactly the same thing as selecting Microsoft.Cpp.Win32.User under either debug or release. So everything affects both configs.
Now, as I understand it, Microsoft.Cpp.Win32... is a single file (at least, a single file for x86 configs, single file for x64 etc.) so the fact that I can't change the configs individually actually makes some degree of sense. But if I can't do it that way, how can I do it?
Appreciate any advice!
Short answer: you can't. See comment discussion under question.
I'm using Eclipse with C++ code via linked resources on Linux. The code analysis index seems to be corrupted (Goto definition lands the cursor close to, but not on, the definition) Refreshing resources doesn't fix it, neither does restarting Eclipse.
Is there a way to flush the index and rebuild it?
Right-click on your project, go under the Index submenu, and choose either "Rebuild," "Update with modified files," or "Freshen all files."
I don't know the difference between those three options, but one of "Update with modified files" or "Freshen all files" usually fixes it for me.
Also, I'm sure you've already done this, but make sure that you're running the latest version of the Eclipse CDT. Current versions seem to have much more reliable indexing than previous versions.
From http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg10390.html, the differences between "Rebuild," "Update with modified files," or "Freshen all files":
Rebuild: Works for entire projects, only. Clears the index and indexes
the files from scratch. When cancelled it leaves you with an empty or
partial index.
Update with Modified Files: Works on a resource
selection. Checks on individual files whether the timestamp or the
scanner-config has been changed and updates the index for the changed
files.
Freshen All Files: Works on a resource selection. Updates the
selected files in the index. The index is not cleared, it is safe to
cancel the operation.
Go to your project properties -> C++ general -> Indexer.
Do this with 'project specific settings',
(or on 'Configure Workspace Settings...').
Deselect 'Enable Indexer' hit Apply.
Select 'Enable Indexer' hit Apply.
This should completely wipe out and rebuild the index.
Neither of the above worked for me (Eclipse Indigo), index still broken and refusing to rebuild properly. Until applied this one:
http://slsam2.blogspot.com/2012/02/eclipse-cdt-index-not-working.html
The crucial bit of the linked post is this:
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code.
I still wonder how Eclipse can uncontrollably shoot itself in the foot like that. I suspect that installing additional packages can trigger it. Perhaps JavaScript support in my case.
delete only the .pdom file under .metadata.plugins\org.eclipse.cdt.core helps, I got the indexer screwed after upgrading Neon.2 to Neon.3 and this seems to solve the problem.
(this comment already exists above but am not allowed to confirm it up there).
I found that I had the global indexer set to 'Use the build configuration specified in the project's indexer settings',
and the project's indexer set to NOT use project specific indexer settings.
Regardless, it was using the same fixed configuration for the indexer regardless of which configuration I had selected.
The fix:
Window-Preferences, C/C++, Indexer. Select "Use active build configuration" in section "Build configuration for the indexer".
Happy days.
Did you try adding -clean to the command line for the eclipse executable?
Eclipse no longer treats your project as a C++ project. Choose menu File/New/Convert to a C/C++ project. It takes a while to index the source code. worked for me
I started with trying Josh Kelleys and mmmmms answers without any luck, but I finally fixed it by checking my include paths.
One way to see them are in the Project Explorer, expand project and there should be an entry "Includes". Inside that, check for a small yellow warning triangle on each include path. If that triangle is present eclipse most likely doesn't recognize the path.
The include paths are edited through right-clicking on "Your project" in the Project explorer, then choose "Properties" --> C/C++ General --> Paths and Symbols --> Includes.
I see three language options, Assembly, Gnu C, Gnu C++. Choose the correct one before starting to add paths (likely Gnu C++). After adding all the paths, -->Apply --> Ok and rebuild index if you're asked to.
My erroneous workspace paths looked like MyProject/MyProject/folder when it was supposed to be MyProject/folder.
For me the "Problems"-view is always slow to update, even after rebuilding index. To be sure that the error is still there, double-click the problems entry so that eclipse opens/reloads the file in question. This often seems necessary for me to update the "Problems" view.
I don't really know if it was eclipse or my scm that messed it up. Anyway, hope it helps someone!
I use Luna and builds with an external makefile.
We just got a new developer and I'm trying to set him up with Dev Studio 2005 (The version we all use at this office), and we're running into a weird problem that I've never seen before.
I have some code that works perfectly on my system, and he can't seem to get it compiled. We've tracked the issue down to his copy of dev studio ignoring the preprocessor directives.
For example, in the project properties under C/C++|Preprocessor|Preprocessor Directives, I add DEFINE_ME. Which should translate to a /D"DEFINE_ME" for the compiler. And it does in my development environment, but it doesn't on his.
I verified that when he checks out the code from the source repository, that he has the same version of the code I do. And if I look in his Project Properties, all of the directives are there. For some reason they're just not getting passed down to the compiler.
Any Ideas?
I recently ran into the same symptom with VS2005. Ultimately I was able to resolve it by explicitly adding my preprocessor defines via the Command Line - Additional options dialog:
Configuration Properties -> C/C++ -> Command Line
When I added '/DPROPERTY' there it was recognized at compile time, whereas adding it under 'Preprocessor -> Preprocessor Definitions' did nothing. Oddly the Command Line dialog did show that Visual Studio was adding the property to the command line, albeit in the form '/D "PROPERTY"'.
Unfortunately schedule pressure being what it is I have not been able to dig into the issue deep enough to figure out what the underlying issue was/is, nor why it seems to work out of the box for some of our projects but not others. Nonetheless the workaround above is worth a shot if you're having this symptom.
Also, credit where credit is due: the idea came from this thread.
Make sure that the project configuration which is being built in the selected solution configuration is the same as the one you're configuring the properties for, and/or that you're configuring the properties for all project configurations. A common problem with new VS installations is that the current active solution configuration is system-specific, and may default to something not matching yours (eg: Release vs Debug).
You can see the project config in the build output, and/or check it in the Configuration Manager.