Xcode always builds all my targets in the current scheme, even without any change - xcode

With Xcode 8.1 I see this phenomenon that even if I didn't change something on triggering Run Xcode goes through all targets of the selected schema and builds them (which is a mix of mostly C++ and some Obj-C code). All images are processed, all scripts run etc.
However, in the build log I see that the cpp files are not really compiled, they are just listed, so the overall build time is not that of a real build. Still, even with a few seconds on each target I get a delay of 10+ seconds (and a lot of file operations) before the debug session starts actually, which is a pain if you need to restart the debugging session frequently.
Is there any solution to avoid this "pseudo build"?

Related

Externally generated projects(premake/cmake) lock up VS2015

I'm using premake5 here.
It generates my solution/project files, when this happens, VS2015 asks me if I want to reload the modified projects.
If I hit yes, this proceeds to lock up the IDE for a very long time.
Anywhere from 30 seconds to 1 minute I'd say.
Does anyone know of a way to work around this? This is super irritating.
It happens even for the most trivial of changes(modify one project, which only has 1 file in it).
I realize this is a VS problem, and not directly the fault of premake/cmake(or whatever build system you are using), but it totally sucks.
As you said, it's VS related :) But I think you have some problems with your installation : for small projects, reloading the whole solutions should be pretty fast : my personal projects take less than a second to reload (2 to 4 projects per solution, ~100 files per project)
Anyway in the usual course of development, re-generating your projects should not happen that often, except at the very beginning when you need to configure everything.
When you need to add a few files, just add them through Visual Studio : you won't have to run Premake again, and next time you run it, the files will be included by your script anyway. You can do the same with small configuration changes : update your project directly in VS, check that it works, and when it does, upadte the Premake script. You won't have to run Premake then.

Xcode 4.3.2 and 100% CPU constantly in the idle time

My Xcode started to behave very heavily from yesterday when working on medium size project (around 200 source files). Project compiles correctly and runs in both simulator and device. I do not use any 3rd party libraries, except few widely used includes (like JSON or facebook ios sdk).
It constantly uses CPU(s) at full speed, even if it is in idle state (no indexing, no compiling, no editing). The usage of RAM is relatively normal (300-50MB).
My machine uses: Core 2 Duo 3.04Ghz CPU, 8GB of RAM and Vertex OCZ 3 SSD drive.
I have tried every suggested solution found at stackoverflow:
Cleaned project
Cleaned Derived Data in Organizer
Cleaned repositories in Organizer
Cleaned xcodeproject bundle from workspace and userdata files as suggested here: https://stackoverflow.com/a/8165886/229229 (it is helping just for a moment and starts again after minute or so).
Restarted Xcode many times (with the same effect as in 4).
Disabled "Live issues"
even Reinstalled Xcode
Nothing helps. In most cases, Xcode indexes the project for a moment, then comes back to the normal performance, but after a while becomes unusable again. CPU jumps back to 95-100% for both cores, intelligence hangs, etc...
I am attaching screenshots of how the Xcode processes are seen by the Instruments:
UPDATE:
After a moment of hope that I solved the problem by moving around few
#import "header.h"
statements from headers to the implementation files and exchanging them with forward declarations ... the problem came back again after a while.
I am adding the console log.
The strange thing is that the logs related to Xcode show up after I quit it, not during the run itsef.
Console logs:
5/11/12 9:27:03.777 AM [0x0-0x45045].com.apple.dt.Xcode: com.apple.dt.instruments.backgroundinstruments: Already loaded
5/11/12 9:27:05.571 AM Xcode: Performance: Please update this scripting addition to supply a value for ThreadSafe for each event handler: "/Library/ScriptingAdditions/SIMBL.osax"
5/11/12 9:27:58.168 AM Xcode: ERROR: Failed to create an alert for ID "enabled" based on defaults: 1
What stopped my nightmare was:
Change Always Search User Path to NO in Project build settings (bolded).
Remove -objC flag Other Linker Flags (also bolded setting).
And then delete Derived Data and wait until Xcode reindexes.
I am not sure which of them helped bacause I changed both of them at the same time and I am so behind my schedule I have no time to test it. I will improve this answer when I reproduce the bug and solution in spare time.
However, there is a hint:
*Rethink and recheck your project / targets build settings.*
It is highly probable that this strange behavior may be caused by some unfortunate combination of build settings.
All my projects does this from time to time. I can shut down X-code and start it up again and it'll run fine for a while, then go back to using 200% CPU time (two cores fully loaded).
My solution is to use AppCode as my primary IDE (has the added benefit of being a much better IDE, but that's another story). I only start XCode when I need to edit storyboards and shut it down when I'm done - usually that keeps the problem at bay.
AppCode runs off the same project files/structure has better and faster indexing and never runs into this issue, so I can't see how this can be a settings/configuration problem - it must be a bug in XCode. Hence, I would not waste time changing your code structure as it will most likely only delay the problem, not fix it.
No way to know if the OP actually had a different root cause, but for me it appears to have been an Xcode glitch with git. Adding / committing my current changes solved my problem. Here is the complete scenario and what I did to get it fixed:
Environment:
Xcode Version 5.1.1 (5B1008)
Macbook Pro OS X 10.9.2
2 GHz Intel Core i7, 8GB RAM
I noticed Xcode was starting to eat 200% of my CPU constantly.
Not sure exactly when it started, but Xcode did freeze up on trying to make a snapshot (400% CPU usage for several minutes until I force-quitted Xcode)
After reopening, I noticed Xcode was still stuck indefinitely at 200% CPU usage.
Closing all projects did not work.
Deleting all derived data and restarting did not work.
Uninstalling Xcode and reinstalling at first held promise, but once I re-opened my main project, the CPU returned to a constant 200% CPU usage. (after indexing finished)
Closing the troubled project did not help. Xcode was now stuck again in forever-kill-200%-of-CPU land.
After looking around Stack Overflow, multiple people alluded to git being an issue.
I have a slightly complicated git repo (has a submodule repo and a subproject within the main Xcode project).
I had pending changes in both the main repo and submodule portion of the repo.
I closed Xcode and git added & committed all my current changes.
Reopen Xcode and VIOLA! No more CPU being killed. Back down to 0.0% idle usage.
Xcode 5.1.x seems to struggle with git in other ways for me too (sometimes does not pick up changes in the GUI, etc.) so perhaps there are Xcode git integration bugs.
It looks like it's spending its time parsing ObjC included in the PCH.
How many PCHs must clang generate? In your project, that would be one for C, one for ObjC, one for C++, one for ObjC++ for each dialect/lang used in your project and any dependent targets. That is -- if you have a dependent library included in your app's PCH and you are hacking on that library, all code sense in the app target must be invalidated and parsed again each time you alter a header included by your pch. And if your target compiles a C file, it will need a PCH for C. If it needs one for ObjC, it will need to generate one for ObjC.
How often do you alter the PCH (or anything included by it)?
Remove includes from the PCH. It's not unusual to see every linked framework included in a PCH (avoid doing this!).
If you change your build or preprocessor settings, it may need to rebuild the code sense index for the target(s) entirely each time.
Have you tried disabling live issues?
On my projects (all of them) it was the autocompletion/intellisense. When I changed one line of code in my .h files, it went haywire, +100% CPU usage (more than one core).
I just disabled it, now I have to think a bit more for myself (like I used to do on windows) and it works great at low CPU usage.
i used to encounter this problem.it is caused by git.Although i don't know the git very well.i removed the file named .git in the project directory and it turned to normal.by the way,the .git is hidden.

When and why should I clean the build in XCode

Every once in awhile, the solution to an aggravating problem in XCode is to hit Product → Clean, and this seems to clear some cache and problems disappear.
But what is it actually doing? And more importantly, WHEN should I be doing this? It seems to be necessary more often when dealing with Core Data, but I haven't really been tracking it.
As a side question, WHY is this necessary? XCode seems to do a lot of stuff in the background (autosave, autocompile, etc). Why doesn't this also just happen in the background?
It's because there are a lot difference when you are working with a very very big project with a lot of files and objects. Imagine that you need an hour to recompile a entire project, so you will think before do this. But in our world, this is a fast task.
XCode use the make program. So, it compile only what was changed.
I can list same cases you need do this:
Always you will create a App for App Store. This safety thing to do.
Always you use the XCode Snapshot. I have bad time when I restore a project and build the app. XCode used old compiled files and a lot of time was lost to search it.
Maybe when you restore a old code with git. Is the same idea of the Snapshot
When you delete or rename a file in project. It don't delete the compiled file, so the program can work, but if you recompile, will see the errors.
When you see that sometime the build have a strange behavior. Or only to have certain that XCode use only your newer files.
I don't remember exactly but i have seen the build use old #defines. Rebuilding can make you more safe about your program. But don't need do this all time.
I am almost certain that XCode loses track of things and sometimes it doesn't recompile (or link, not sure) everything is needed. I have to resort to clean and build all most often than it should. Maybe it's just me, but I doubt it... XCode is the IDE with most bugs I have worked with

Visual Studio 2008 keeps rebuilding [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Visual Studio keeps building everything
Visual Studio 2008 keeps rebuilding the entire project as if every implementation file was modified. This happens even if no files were modified. Hit build button twice in row, and the entire projects gets rebuild twice. This doesn't happens on another box. The OS is Windows Vista.
This is very annoying. What could cause such a behavior?
It is a C++ project.
Some ideas to try...
As #David Paxson said in the comments, with some languauges (e.g. C#, VB) all the projects will appear to be "built", but the compiler will skip through the ones that don't need to be built much more quickly, even though they are still listed in the output. So it may simply appear to be rebuilding everything. Also, with C#, Visual Studio sometimes runs the project several times in a row, and sometimes it will decide for no obvious reason that it needs to "rebuild" the projects, but this only usually takes a few seconds extra unless you have hundreds of projects.
Restart Visual Studio (or even reboot the PC entirely).
Do a "Rebuild All" of the entire solution to clean out any old cached information and ensure all the output files are up to date.
If you use source control, then even better is to check in all of your changes, then delete your old source code folder (or safer, rename it somewhere out of the way until you know you don't need it) and force-get all the latest source code from source control again. This means you have a totally clean starting point (a clean or rebuild-all doesn't quite clean everything away, unfortunately). I do this every 2-4 weeks to keep everything running smoothly and totally in sync with the Source Control code.
If anything modifies the datestamps of any files in your build, then this could trigger a "need" to rebuild everything. Check that your system clock is set correctly, that there aren't any datestamps of source files set to times "in the future", and there are no applications running that could possibly "touch" any of your source files.
Check this option: Tools->Options > Projects and Solutions > Build and Run : "Only build startup projects and dependencies on Run". If it is unchecked, then VS will try to rebuild all projects every time, rather than only the dependencies of the startup project. If you have a large solution with a bunch of mostly unrelated projects in it, this is a very helpful option to set.
If there are projects that you don't need to build every time, then use the Configuration Manager to disable building of those projects in your current build (or create a "Debug Fast Build" configuration so you can switch quickly between a full rebuild and a partial build). Or move projects that don't need to be built often into a separate "libraries" solution and reference/link the output files (obj or dll) form your application's Solution, so the libraries only need to be rebuilt if you edit their code.
Lastly, make sure you're doing a "Build" and not a "Rebuild" :-)

Why does 'clean' magically fix mysterious bugs in my app?

If I ever have a problem that is not showing up as a warning, but makes my app crash on runtime, sometimes I'll build->clean and often it this unkown bug disappears. This happens mostly when I import new images into the project(replacing old ones) or when I make major syntax changes with my code.
F'in 'Clean all Targets', how does it work?
Thanks
When you build for the first time, all of your code is turned into object code. That way when you make a tiny change to one file, you don't have to recompile your whole project, just that one file.
Now sometimes things go funny and stuff doesn't align properly, or dependencies aren't updated and boom crash. The build system is supposed to detect this but every project I've worked on has had this problem at one time or another.
Build clean deletes all the intermediate object code and recompile from scratch.
When you clean your project, you force your entire application to recompile itself. Maybe one of your resources was compiled into your application in a way that required you to recompile everything when changing the resources?
What sort of application are you building - do you use threads? I would make sure they aren't race conditions, because their trademark symptoms are sporadic non-reproducible errors.

Resources