Build options changed, rebuilding all

Status
Not open for further replies.
sumotoy

sumotoy

Well-known member
Hello,
since I'm using IDE 1.6.2 I have this annoyng problem, every time I send the code to Teensy I got the infamous "Build options changed, rebuilding all" and the entire code it's compiled again even if I changed just one bit. This is really annoying and it's a waste of time. I have tried move IDE in a folder in C and create another folder (in C as well) but nothing change.
Did you have any suggestion? I know it's mostly Arduino IDE related but maybe I got a fast response here so sorry about that.
Thanks in advance
 
Yeah, it seems to be even worse in the newest Arduino versions. I'm seriously considering a huge patch to make a fast build optimized for Teensy....
 
I just tried the Arduino Pluging for Visual Studio and it doesn't recompile all the code as arduino does all the time, seems an arduino IDE issue!
 
PaulStoffregen said:
Yeah, it seems to be even worse in the newest Arduino versions. I'm seriously considering a huge patch to make a fast build optimized for Teensy....
Click to expand...

That would be great! I've not commented on this as it is an IDE issue - but any TOOLS change forces a rebuild all - I supposed that was deemed needed to make sure core changes and device specific libraries were picked up?

The other IDE issue is having multiple instances open - that now all have their very own TEMP directory for build files is great for two builds using the same Tools:device/params. But as soon as you change one to say build LC and the other to build T_3.2 or Serial .vs. RAW_HID - you have to rebuild all as you change - then change back on returning to the other instance as these are global across instances - and then do a rebuild all there. This caused me grief building Frank's TeensyTransfer as RAW_HID on my Prop Shield and something else on a second Teensy that often ended up with RAW_HID on the next build.

If each IDE instance - with a unique TEMP directory - retained it's own TOOLS settings that seems to be at the core of this as each device change seems to partially rescan for association within the IDE load of device libraries. This is typically obvious with the delay to the menu system to become functional - especially on my older i5 Windows laptop when one device is TEENSY_3 and the other is ESP8266.

My solution for ESP8266 was to set up a Remote Desktop on my downstairs computer for OTA updates with external editor and then locally program my Teensy that hosts the ESP8266. If I got a new latptop or worked more on my on my desktop downstairs I'd install Visual Studio + Visual Micro.
 
I'm currently choose to use Visual Micro + Visual Studio just for this problem, Visual Studio it's a gigantic monster to use as IDE for microcontroller, it has some nice feature, but it's hudge. It took several hours to install and yesterday it took 3 hours just for an upgrade and open it take quite long, but today I got to pay licence and now I'm stuck with this until Arduino IDE team fix this and some other problem (like compiling speed that I don't know why on arduino it's slower).
I really don't think it's your fault Paul, I have another Arduino IDE 1.6.8 in a laptop and do the same thing for almost any CPU, this is clearly something wrong in Arduino IDE and they have to fix asap or many people will forced to use something else, yesterday it takes more than a min every time I push upload, it's just an incredible waste of time
I've take a look in some forums, someone disconnect Antivirus, others moved folders in C, others claim there's a space or special char in some path... With 1.6.8 nothing work, it always 'rebuilding all'.
I also noticed that compilation time of the whole thing it's slower with Visual Studio, how can be? It uses the same stuff...
Currently working with Visual Micro + Visual Studio it's blazing fast and Teensy works perfect, not problem at all.
 
Last edited:
sumotoy - I tried VisualMicro just as it broke in the early 1.6.x spasm of IDE updates - then haven't gotten back because I've happily filled my notebook hard disk. I have a DVD of the VStudio 2015 at hand - but haven't dared to burden my notebook machine yet :( - and my way better desktop has had new set of SSD and HDD here in a box for 6+ months to clone and swap before I take it to Win 10.

This certainly is an IDE issue - I hoped when they went to TEMP per instance they would end up cleaner and faster - but that isn't perfect, or complete as I noted. It isn't a Teensy issue - but if there is an IDE adjustment or fix Paul seems to be aware enough to see it.

As far as it being slow - I just blame JAVA. I only see 'rebuild all' after a TOOLS change - but it always spews by lots of verbose lines - still gets done on my lame notebook to Teensy in under 10 seconds.

<edit>: Actually 4 seconds to complete a back to back rebuild on WINDOWS 10 with no changes <> simple sketch :: Sketch uses 17,768 bytes

<edit>: Actually 9 seconds to complete a back to back rebuild on WINDOWS 10 with no changes <> FASTLED Prop Shield sketch :: Sketch uses 43,284 bytes
 
Last edited:
jonr said:
So "recompile everything, every time" isn't the expected Arduino IDE behavior? :).
Click to expand...

GOSH NO - at least not on my 1.6.8 Windows install - as noted recompiles are measurably faster than "Build options changed, rebuilding all"
My 4 second recompile - takes 15 seconds on changing CPU speed.
My long 9 (actually under 8) second recompile - takes 23 seconds on changing CPU speed.
Click to expand...

PaulStoffregen said:
Wouldn't be the first time I've hacked Arduino to speed things up....
Click to expand...

Would have been surprised to hear otherwise :) - the fact that you have a video link . . . also not surprising :D

Wow - nearly year old work in Sept 2011!


Paul - one oddity I've noticed as a 'user caused' side effect of the above - when I started a compile to see I did RAW_HID when I didn't mean to - I set to USB_Serial (or the other way around if I needed RAW_HID) - then hit Upload again. That seems to stop and restart a new build - but there are things marked as 'not changed' since last compile - then things "don't complete" and I had to find a way to trigger a 'Compile All' to cleanse the affected files. It is NICE to have the re-Upload start and not flash bad code - but as noted switching between IDE instances shares the settings that are wrong for other instances - and in this TOOL change case (during a build?) - it misses the need for 'Build options changed, rebuilding all'

<edit> Paul: (re my post #5) I guess the best I can think of to ask for is - if I return the IDE settings to those last used in this instance - after changing in another instance - that it would realize the instance specific TEMP files are indeed are good to re-use when the source times agree.
 
Last edited:
10 second after pressing "Upload" the button comes pressable again, but this time the previous upload command gets killed explicitely
Click to expand...

That should help fix the symptom - for 10 secs will stop my "'user caused' side effect of the above" - then when active again properly terminate in process compile so maybe prevent the hidden TOOL change? A shame they didn't add an abort button - like with email send or forum post touching the UPLOAD makes you want 'UNDO', especially when there are active electrons poised to act on completion.

Those state items (like avoidMultipleOperations ) aren't likely shared across instances? I wonder what happens when you compile in two windows? Given the verbose output follows to whatever instance gets focus - I assumed that was nasty and probably tried to never do it.
 
I discovered perhaps a common cause for : "Build options changed, rebuilding all"

If you open a "READ ONLY" example from a library each edit and build causes : rebuilding all

This was the case for me building in my "Sketchbook location" 'USER libraries' folder: "C:\tCode\libraries\TFT_ILI9163C\examples\SomeBars_example\SomeBars_example.ino"

The IDE allows this and makes a TEMP copy to save and rebuild your changes - this must be in the SCAN as a library change in some way.

Doing a SAVE AS to a personal folder - outside of the "Read Only" area eliminates this.

Paul: Perhaps there is an easy way to differentiate this on the rebuild search?
 
Has anyone suffering an always 'rebuilding all' confirmed if it is from using a 'read only' folder example? My Windows 10 system w/IDE 1.6.8 otherwise only does this on a "Tools menu Change"
 
i only get rebuild on tools changing when i recompile esp & teensy, otherwise re-reprogramming is faster, i basically give "Everyone" read/write access to the "Arduino" folder
 
Status
Not open for further replies.
Back
Top