Bad sketches should build (fail to build) faster!

[GoogleCodeExporter]

What change would like to see?
Compile the user sketch first, before the core and installed libraries, when 
using the verify or upload buttons.

Why?
Since the user sketch is more likely to contain errors than the core libraries, 
this would result in much faster turnaround of those errors, since they could 
be reported before much of the source code involved needs to be compiled.

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?
I don't think so...  (will try to implement...)

Original issue reported on code.google.com by wes...@gmail.com on 8 Nov 2010 at 5:33

[GoogleCodeExporter]

These diffs seem to work on simple sketches, and look like they should always 
work.

Original comment by wes...@gmail.com on 8 Nov 2010 at 6:14

Attachments:

• Compiler.java.diff

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 11 Nov 2010 at 12:17

• Changed state: Accepted
• Added labels: Component-IDE, Milestone-0022, OpSys-All

[GoogleCodeExporter]

The include path list for libraries needs to be built before compiling the main 
sketch.  Without performing that step first, which happened automatically in 
the old order, any sketch that uses libraries will fail to compile.

Maybe it's ok to compile the core with all those extra library include paths, 
but to preserve compatibility those extra include paths should probably be 
discarded from the list before compiling the core.

Original comment by paul.sto...@gmail.com on 15 Nov 2010 at 3:45

[GoogleCodeExporter]

This patch rearranges the compile order, but with proper handling of include 
paths.

It also uses dependency checking to avoid needlessly recompiling files when 
their sources haven't changed.  In the common case of editing a sketch, the 
libraries and core files are only compiled the first time.  Even if you edit 
the core files, even headers, the dependency checking allows Arduino to only 
recompile the affected files.

Original comment by paul.sto...@gmail.com on 16 Nov 2010 at 4:00

Attachments:

• arduino_efficient_compile.diff

[GoogleCodeExporter]

Original comment by dmel...@gmail.com on 17 Nov 2010 at 4:33

• Removed labels: Milestone-0022

[GoogleCodeExporter]

Here is a patch for only the (low risk) build order.

This does NOT include any (higher risk) dependency checking and reuse of 
previously compiled files.

Original comment by paul.sto...@gmail.com on 26 Nov 2010 at 10:40

Attachments:

• arduino_build_order.diff

[GoogleCodeExporter]

https://github.com/arduino/Arduino/commit/6750e679afe8b83e38d5efbb17859bbd686eb8
1e

Thanks for this, it makes a huge difference in the way it feels to compile 
sketches (at least when there are errors).

Original comment by dmel...@gmail.com on 27 Nov 2010 at 5:41

• Changed state: Fixed
• Added labels: Milestone-0022

[GoogleCodeExporter]

Also, Paul, you should probably open a new issue for the extended patch of 
thorough dependency checking.

Original comment by dmel...@gmail.com on 27 Nov 2010 at 5:43

[GoogleCodeExporter]

I'll prepare a new patch for the dependency stuff in a few weeks, and create a 
new issue for it.  In the meantime, I'm going to do more testing within an 
alpha release for Teensy.  Hopefully that might catch any subtle bugs.

If you're going to use the menus patch, it would be best if I wait to prepare 
the dependency patch until after the menus are implemented.  There are some 
minor interactions between these patchs, so preparing and testing the 
dependency patch against source with the menus would be much safer.

Original comment by paul.sto...@gmail.com on 27 Nov 2010 at 7:34

[GoogleCodeExporter]

I'm planning to apply the menus patch to the new-extension branch (which is the 
1.0 branch, but needs renaming).  In any case, the dependency checking patch 
isn't a top priority for me (although after seeing the speed increase from the 
simple re-ordering, it is appealing), but I do want to make sure it doesn't get 
lost because this issue was closed.

Original comment by dmel...@gmail.com on 29 Nov 2010 at 4:31