I have searched a net for some nice code and suddenly I have bumped on a one, however it's been worked in Eclipse, and since I don't have an Eclipse( and I am not planning to instal it anyway ) I can't properly compile it on my VS10. The thing is that all linker references are mapped in .cproject and if I create an app in my VS10 and paste all the headers and cpp files to it, I still can't build it, 'cause it freezes once it gets up. The main issue may lay in .cproject, so my Q. is can I somehow transform .cproject to .vcproj without much fuss so that this can work on my VS10 as well? :)
You can avoid the fuss partially by using CMake (http://www.cmake.org/)
You need to extract the source files' list from the .cproject and run the CMake to get the .vcproj/.vcxproj (basically, you create the "metaproject" for "all of the IDEs")
If you require some extra compiler setup then the fuss is unavoidable.
Related
Recently I obtained a solution which has been created on another person's machine. I have been banging my head into the monitor in the past 2 days trying to fully migrate the solution to my machine. I have been manually changing the directory addresses of the solution and have not been able to compile the solution although I think I have corrected more than 100 paths as of now. Here's my first attempts to migrate the solution to my machine and resolve the issue of not being able to open any of the files.
Now I can open all the files in each project on my machine (after manually changing their paths). However, I am still getting the same errors and I'm not able to compile the project. Below is a picture of the errors I'm getting:
And here's the output log when trying to compile the project. So I wonder, can someone give me some advise on how I should go about doing the whole process automatically? In the output log I see there is a F:\Virtual ... path which indicates the solution been created on a virtual machine. However, I am not using a virtual machine and am not able to find the file file containing that path (F:...) so that I can change it to the correct one (I even do not know what the correct one should be since I am not using a VM).
If you are not able to help me through the description I gave or the output log file, you can download the whole solution from here and then give me some instructions on how I should go about compiling and using it. I really appreciate your help.
Chances are that someone went rogue on the project file, because normally all paths are defined in a way that is relative to the project or solution, making them portable.
In order to fix this, I see two options, either set up the project files from scratch or keep on hacking on them until they compile. Whichever path you take, keep in mind that VS supports placeholders like $(SolutionDir) you can refer to when setting up paths. If that doesn't work, please try to extract a minimal example.
Also, make sure you have a version control system set up, so you can retrace your steps. This should be standard in any software development, but considering the state of the project I wouldn't be surprised to find other, hairy places there.
Why would a project be able to compile and find the necessary header files, and then I add a line that it cannot find, it does not compile, I remove that line (the code now looks exactly as it did when it compiled the first time) and now suddenly it cannot find the header files that it could find only a moment ago? I did not change any of the file structures, absolutely nothing changed other than adding a line, removing it, and everything is broken.
I have followed every instruction in the Ogre3D tutorials up to building the first tutorial. Everything works perfectly fine and the first tutorial compiles and runs. So I decide to see if I can get a different tutorial to do the same thing, but alas the compiler throws an error: No such file or directory when looking at the line #include "Ogre.h". So I go back to the first tutorial's framework, I include all the lines and it still compiles as expected and then I decide to remove all of the source files and everything, and I take the very first include directive from the BaseApplication.h, the line is #include <OgreCamera.h>, and I put this lonely line in a single file main.cpp and attempt to compile this 1 line program. The same error occurs, it cannot find OgreCamera.h! What??
So what is so special that the tutorial framework compiles but when I try to do basically the exact same thing it throws a fit.
Update
Even stranger things are happening now... I added the line #include "Ogre.h" to the tutorial framework's BaseApplication.h file, it cannot find Ogre.h. So I remove that line and try to compile the program (which compiled not more than 10 seconds ago) and now it no longer can find OgreCamera.h! But it has literally not changed at all in any shape or form that I can tell. This is confusion of maddening proportions now!
Where the header files are resolved from is not defined in the code itself, but in the IDE and/or code::blocks project preferences. This tutorial is more relevant for setting up the search directories for Ogre header files.
If it was working a short while ago and not now, I would suspect you have probably made a simple mistake like switching from Debug to Release, having only configured the search directories for Debug build in the project properties. (Clicking build options defaults to selecting Debug rather than all configurations). Try to re-add the Ogre directories in both Debug and Release builds.
Code::Blocks also lets you add search directories globally for the IDE, in the compiler and debugger settings for commonly used libraries. You can also create a global variable for the Ogre SDK location to make it simpler to add to each new project. (#ogre.include), rather than adding the full/relative path.
I believe I know what I have done to myself here.. and recreated the problem
I followed the tutorials and setting up an application to the letter, and was having some other problem when I decided to copy the entire project I had already made doing the tedious setup things necessary. Without realizing that copying the entire project by simply copy-pasting the directory does not carry the tedious setup things necessary. And so, probably without paying attention to the "Target is up to date." build message, assuming it compiled I changed the files, it did not compile as expected, and then changed them back to their original state, and it still did not compile because they were no longer up to date.
I am going to remember this... for a long time.
I have updated my Ubuntu box to 11.10 and then Eclipse also have been updated to 3.7.0 Indigo with CDT 8.0.1
Then the following problem occurs:
I have included the vector header file but the compiler said that Symbol 'vector' could not be resolved. I also defined #define int Comparable, but Eclipse also said Symbol 'Comparable' could not be resolved and so on....
Although lots of errors occur, compiling was finished successfully!
I have tried to use g++ to compile the code, it had no problem.
The problem is that there are a bunch of include directories that are missing from the indexer's perspective.
Adding the following worked for me, but may depend on your particular setup where they actually exist:
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
They can be set in Project>Properties>C++ Include Paths
Presumably, in the future, the platform specializations for the CDT will included these automatically. I recall reading that somewhere, but cannot provide a reference.
Time after time a crash of Eclipse, the VM or the computer or even just long months of development start to wear down the stability of the workspace where Eclipse stores everything.
Check the <workspace dir>\.metadata directory to get an idea of just how much Eclipse generates and stores in your workspace. Every time you add a plugin, upgrade a plugin, remove a plugin that puts and changes information in your workspace.
A proof is that this issue usually comes just after upgrading Eclipse. (In my case to Indigo).
The easiest way to fix up a dusty workspace is using the -clean command line argument to the eclipse.exe executable.
Eclipse help docs tell us what this command does:
if set to "true", any cached data used by the OSGi framework and
eclipse runtime will be wiped clean. This will clean the caches used
to store bundle dependency resolution and eclipse extension registry
data. Using this option will force eclipse to reinitialize these
caches.
There are three ways one can use the -clean command line argument:
Edit the eclipse.ini file located in your and add it as the first argument on the first line.
Edit the shortcut you use to start Eclipse and add it as the first argument.
Create a batch or shell script that calls the Eclipse executable with the -clean argument.
The advantage of step 3 is you can keep the script around and use it each time you want to clean out the workspace.
This page solved the problem to me!Hope it can help everybody else.
In the project properties, go to C/C++ Build > Tool Chain Editor, tick Display compatible toolchains only, and select Linux GCC and click Apply button.
Now if you go to C\C++ General > Paths and Symbols, you will see new list of include paths added. If you rebuild index, the error messages should go away.
The code analysis is causing this. It's not actually compiling the code but just doing some static checks for quick feedback. Unfortunately I don't know how to fix it, I just disabled it. Sorry I'm at work so I don't have CDT in front of me but I think it's something like:
Window > Preferences > C++ General > Code Analysis
Go there and un-check all the boxes to disable it.
When you create a C++ project (in my case from existing code) you have to set the 'Toolchain for Indexer Settings' to the compiler you use ('GNU Autotools Toolchains' in my case).
After this 'Path and Symbols' will show the correct path to the include files of your compiler.
The bugs will disappear.
This setting was useful only during creating the project, setting it later did not help.
In indigo 3.7.2 version (and up may be) your changes can be effect after reindexing. Eclipse ask for "reindexing". Lower versions can require a manual reindexing header tags etc.
Updated index option to active build configuration works for me,
also I removed some files from the file list of being indexed up-front,
Ok here is what worked for me:
deleted the path to the header files I created from the include path
compiled the project (obviously the compiler complains since it is missing user-defined headers)
reinserted the path to the header files I created
compiled the project again - worked perfectly
I can't explain the case :(
I am answering here because this is the closest question to my problem.
I used QT Eclipse integration with Helios (3.6.2) with no major problems. I was using mingw 4.6.2, which I had installed to c:\mingw. I wanted to upgrade to Indigo, which fixed some minor issues I was having with CDT.
However, under Indigo (3.7 SR2) Eclipse began underlining trivial functions, as being unresolved, such as:
function 'fprintf' could not be resolved
function 'memset' could not be resolved
even though #include was not underlined, could be opened, and included fprintf in the header. And even though the code itself compiled fine.
If I went back to Helios, the problems went away.
I tried reindexing, to no avail. I checked my include paths, and they were:
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
At first, I had just included the first, but not the second. But then I searched for "unresolved includes", and stdio.h was including stdarg.h, which wasn't in the main include folder of mingw, so I added the second. But still, printf was not resolved, and there were no more "unresolved includes".
I created a new C++ project with one class. I added stdio.h, the paths above, and a call to fprintf. It was underlined! Even though other things from stdio were not underlined.
Now I knew that it wasn't just a Qt problem.
I worked around on this for a while before I read the bottom post here suggesting removing the include paths and compiling. I didn't believe it would work but gave it a shot. Amazingly, even though the compile failed, the error went away!
It was then that I took another look at the include paths. They had been updated by the compile step to the following:
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
These were marked as "built-in" values which I assume means they weren't added by me and could get updated the next time I run a build.
So, I guess the lesson is, including every single include path under mingw, even if Eclipse doesn't find it to be an unresolved include.
The next step was to put all these paths into my Qt project. Unfortunately, after doing so, the unresolved functions were still there. It appears to be some sort of bug with the Qt C/C++ include paths which are different from the CDT C/C++ include paths.
I'm having a weird problem with Visual Studio. Whenever I change my code and build, even though I get the notification that the built was successful (and if any, it also shows errors in code and doesn't build) the executable is actually the previous build. This is getting really annoying and frustrating.
If I put a breakpoint on the new lines, the breakpoint gets disabled and it says
The breakpoint will not currently be hit. No executable code is
associated with this line. Possible causes include: preprocessor
directive or compiler/linker optimization
If I put a breakpoint on old lines of code, it stops processing but shows me this message
The source is different from when the module was built. Would you like
the debugger to use it anyway?
I never had this problem before and the source code in on my laptop's hard drive. It saves right away. The only way to get around this to Clean the entire solution manually every time, instead of basically pressing F5.
Thanks everyone for their suggestions. My mistake was that I defined the classes inside .cpp files, this somehow caused the linker to do weird (caching probably) stuff and link the old objects. I renamed the file to .h and everything's working as expected.
Perhaps your code is not built, or is built in a way you don't expect.
You might check by inserting a #error foobar preprocessor directive somewhere. If no error shows when building, you know you are in trouble!
But I never used Visual Studio (I'm only using Linux) so I cannot help more.
It might be that you have set main project some other project and building that.
make your project that you want to work on as "Main Project " by set main project available in menu bar.
I think you are using source files from another project (ex: if you are using a dll say, my.dll (which was built using some source files say, mycpp.cpp ); in your current project).
When you debugged into the file (mycpp.cpp), maybe you modified it.
Hence you need to rebuild the dll (my.dll) first in the project in which you created my.dll .
Or
Maybe you have opened a instance of mycpp.cpp in a window & debugging in another window.
you should rebuild the dll.
If you are not using files from another project, then I cant guess the cause...but still I would recommend using rebuild rather than clean & build.
please clarify your Question a bit.
#David expecting a reply from you...
I was looking for an answer to this issue since I was also stuck with it. A colleague of mine just gave me a solution that works. Yes, it seems really stupid, but it did the trick for me.
Our solution has many projects. He told me to select the project that I wish to break into and set it as the startup project (right-click on the project name and pick "Set as startup project"). I was desperate, so I tried. To my amazement, it works.
Since I have this window opened, I thought I'd share it in case someone else is stuck with the problem.
I faced the same problem. But reason was not as yours.
Then I just restarted the visual studio and it ran as expected.
hey the title pretty much says it all. i have been trying different methods from internet sources, but whenever i try something goes wrong..this is where i got Box2D
in cMake, i get a bunch of errors when building it(i was going through the steps in the readme.txt, but onfortunately, theyre for Visual C++...)
so im wondering hot to set this up as i guess a library (.lib or .a) and use it in my project(my friend passed me his library and when i loaded it in and tried #includeing the box2D headers, they didnt read at all(i got a list of undefined errors) also his box2d was i believe made for linux/unix so i think thats the reason...)
if anyone can help provide some steps that would be nice.
thanks for reading.
Assumptions:
You have installed cmake.
You have installed Code::Blocks/MinGW to C:\codeblocks.
You have downloaded Box2D and extracted it to C:\Box2D_v2.1.2.
If any of those are wrong, modify the paths to match what you have.
Start->Run->cmd.
Navigate to the Box2D "Build" folder:
cd C:\Box2D_v2.1.2\Box2D\Build
Create the makefiles:
cmake -G "MinGW Makefiles" ..
Do it:
mingw32-make
This will throw some warnings, but should work almost completely. Then, near the end, it will error trying to compile the Testbed. AFAIK, there is no way to compile the Testbed using MinGW (you have to use Visual Studio, I believe). Luckily, an .exe of it is available on the Box2D site.
In the Box2D\Build\Box2D folder, there should now be a file called libBox2D.a. Copy this file into C:\codeblocks\mingw\lib.
Copy the Box2D\Box2D folder (the one containing Box2D.h) into C:\codeblocks\mingw\include.
[Thus, after this step, you should have a file C:\codeblocks\mingw\include\Box2D\Box2d.h, and NOT C:\codeblocks\mingw\include\Box2d.h]
And that's it. You should be able to compile and run the "Hello Box2D" example. Don't forget to link to the library.
[EDIT]
From the looks of your error, I'm going to guess that your MinGW Path environment variable is not setup correctly. Which is unusual, since when you install Code::Blocks/MinGW it usually sets it for you, I believe.
Anyway, (these steps may vary slightly depending on your version of Windows):
Right-click on "[My] Computer"-> Properties -> Advanced System Settings
Click "Environment Variables"
Depending on which Windows you have, you may see User Variables and System Variables, or it may be just one group (I can't remember the name). Anyway, create a new System Environment Variable called MINGDIR, with the value C:\codeblocks\mingw or wherever you installed it to. Then, find the variable called Path (or PATH) and append this to the end: C:\codeblocks\mingw\bin. Put a semicolon at the end of the previous entry, and do not use a space.
Also make sure that C:\CMake\bin is present in either the System Variable called Path, or the user variable called Path. If not, append it to the end.
I think that's it.