Visual Studio 2017 - Changes not being built when specific source file changes - c++

I have been working on a simple C++ OpenGL application in Visual Studio (using glfw, glew, glm libraries as well), and some time last night I started having issues when debugging my code, and only when making changes to one file. I can't remember what caused it so I will just describe the situation.
The way I am testing is by toggling a line to rotate the camera every frame to be commented out. So for example I comment out the line, the camera continues to rotate after hitting F5 to debug. I manually right click->rebuild (just building doesn't work), hit F5, and now the camera no longer rotates which is the expected result. Additionally, if I add a breakpoint in my camera class file (and only that file), I get an error message if I don't rebuild:
This is most likely because the file that is built does not have the changes from the current source code file.
Everything is working as expected if I make changes in other files, or add breakpoints. The current way I have the source structured is "main.cpp" includes "loophelp.h" which includes "Camera.cpp" (the problem file). Things I have tried:
Under "Build and Run" uncheck "Only build startup projects..", set the first drop down to "Always build", and the second drop down to "Do not launch"
In configuration manager, make sure "Build" is checked for the project for the correct configuration and platform
Create a new file with identical source code as "Camera.cpp", delete "Camera.cpp", and use the new file instead (adding it to the solution and renaming all references to "Camera.cpp"
Restart Visual Studio, restart my computer
Create a completely new solution+project and reuse the source files
I found this question which seems to be a similar problem but none of the answers worked for me or the OP:
Visual Studio need to rebuild solution for every change

Related

How to use VS Code C/C++ configurations properly?

I am new to VS Code and, coming from VS, I'm struggling to understand how to set up different configurations using the Microsoft C/C++ extension. I followed the documentation, but it seems to me that the content in c_cpp_properties.json is only affecting Intellisense and has no correlation to the actual build, which is set up in tasks.json. The configurations I enter are showing up and selectable at the lower right of the editor window: Intellisense reflects this by apparent knowledge about include folders, etc. However, when I build or run, they don't have any effect, I get errors such as "No such file or directory" for included files. As far as I see it, this is not mentioned in the documentation at all.
How can I make use of the actual selected configuration for the build system?

Changing .fl file in fluid doesn't change the UI when run with Visual Studio

I am working on a C++ project on Visual Studio which relies on UserInterface.fl file for its GUI. Intuitively I would understand that changing the UserInterface.fl file with FLTK would allow me to see those changes on actual GUI when built and run with Visual Studio, however that doesn't happen.
I have already tried restarting Visual Studio and rescanning and rebuilding the project but it hasn't helped.
The .fl contains the following lines of code to which I have tried to make changes as well to see results, but without success.
header_name {UserInterface.h}
code_name {UserInterface.cpp}
I would expect the changes to be visible on the GUI as soon as I change the UserInterface.fl file using FLTK without even having to alter the UserInterface.cpp or UserInterface.h files.
Thanks for any help in advance.
FLTK's fluid environment is completely different from your Visual Studio .sln solution. Thus your files would not automatically update to show the changes made through Fluid. However, you should be able to find the option of "Write Code" under the "File" menu in fluid. The shortcut is "Ctrl+Shift+c". This writes your code to the corresponding .h and .cpp file.

Turn off Visual Studio popups

I have a large project that I have to load and work on. Nothing I can do about it - just load the solution and all projects within it.
Problem is that first several minutes VS loads project one by one and it constantly inform me about it by constantly displaying some "Loading project is required..." window. Sure, I know it is required, but cannot it be somehow done in the background? I would be content if I could just open some text editor and tune configs or read documentation without popups stealing the focus.
It happens on all project regeneration (we use GYP) - since VS solution and projects are generated each time I have to work on new C++ defines/flags/dependencies settings I have to sit and watch VS spamming those little windows.
It has another drawback - if right after project regeneration I'll try to build it VS will "block" - it will complain that it cannot close the project when build is running and I have to terminate the build in order to "close" the project. I understand that what it really does is close and reopen it in order to update settings... but popup that locks whole IDE certainly makes it more annoying.
I know that I can disable automatic reload of source file when it was edited outside by e.g. Sublime Text. Are there some solutions that would allow me to do the same for projects? Some settings, plugins or register entries that would prevent those windows from spamming or which would reload project when it suits me? It's really annoying when I have to switch to ST each time I regenerate and build projects because Visual Studio will stay locked until the build is finished.
I have a similar issue with CMake-generated Visual Studio solutions. While I don't have a solution, I've found a workaround which works just fine for me - close the solution before re-running the generator, and open it again when the re-run's finished. Under normal keymappings, it's Alt+FT to close, and Alt+FJ1 to open again.
Disable Intellisense, Visual Studio usually takes a great deal of time during project load parsing headers and building up its intellisense database. Disable that and see if your load times improve.
Might not be applicable if you can't change your solution, but I'd try to move less important modules/projects to DLL or prebuilt libraries. Candidates for this are 3rd party / external libraries that you don't plan on changing or potentially really stable sections of your code base.
Good luck.
The VS system records the last solution associated with each project in the .SUO files. If you delete the .SUO files, you will then be able to open the project files individually, and then save a solution containing just the projects you want to open.

Why doesn't my visual studio build properly?

Okey, I am REALLY having problems with the Visual Studio 2012, and looked all over for a solution, with no result.
So the problem is this... Usually the play button, starts building and debugging in the end running the program. And each time a source file is updated, it should do that again. Well, for me it does not. Every time I write something new in a file, I need to REBUILD the program and then hit play, when before, just hitting the F5 button would do the trick.
The thing is, I have checked, all probable causes that were diagnosed over the internet, so no it's not related to the settings in visual studio, and no, it's not a timestamp issue.
The oddest thing though, is that sometimes, some of the files inside the project look excluded( they have a tiny red circle on them and I have to select and reinclude them). I do not understand why that happens, they were not implemented by me, they are just some "dependency" files on which other classes that I am ussing are built.
Furthermore, the problem of not updating the program. At the moment I have 2 classes. If I write code inside one of them, F5 will work properly and run with the expected modified result. On the other class though, nothing will happen. F5 will find no errors, but it will run without any modification, altough there was code added in one of the classes.
This is really driving me crazy, and I really need a conclusive answer. Why are the dependencies file being involuntarely excluded? Why does visual Build correctly changes from one file but not from another?
You made your visual studio to do it (i.e to launch code with errors).
By default when there is an error you get this popup:
Now if you tick the checkbox - VS will not bother asking you again;
even when errors occur - it will just execute last executable that it has.
To revert this change - go to: Tools > Options > Project & Solutions > Build & Run:
Change this setting to *Prompt to Launch and you are done.

How can codeblocks go from finding header files to not being able to find them, when none of the source code has changed?

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.