bperrybap:
Compiled archives could live in the temporary build area.
This would essentially be a further optimization of of what Teensyduino was doing.
It would create an library archive for each board type as it is used and then
when possible re-use it when switching between board types or sketches.
It already does reuse the compiled library and core files across multiple sketches. But reuse between board changes is not done. Teensyduino also treats a USB Type or CPU Speed change as a board change.
I don't intend to work further compiled file reuse, partly because the remaining cases are well into "diminishing returns", and partly because of the long process to get patches accepted. Further work would probably require very substantial changes, which would have very little chance of being accepted into Arduino.
Or even simpler, the IDE could build all the libraries for a board into an archive
inside the build area the fist time a sketch was was built.
It would be similar to the way the core library is built, only smarter.
Then, no library files would need to be rebuilt during that IDE session for that board.
It already reuses .o files for libraries.
For example, if your sketch uses Servo and Wire, on the first compile the sketch, Servo, Wire and core files are compiled. Thereafter, only your sketch is recompiled (unless you happen to edit the libraries or core with a text editor...) If you add another include in the sketch to start using Stepper, on the next compile, Stepper is compiled, but Servo, Wire and the core files are all reused.
Sure, there are lots of other ways it could work, like pre-emptively compiling all the possible libraries. But this approach makes minimal changes to the structure of Arduino's Compiler object and overall build process. Even that has taken half a year to get accepted, or well over a year if you count an earlier version I submitted but was rejected.
Does the IDE currently use the .d files it creates?
(I assume it must use them with the Teensyduino "smart build" update?)
Yes. There is a release candidate available, so you can try it on regular Arduino boards. Here are the files:
Mac OS X: http://files.arduino.cc/downloads/arduino-1.0.1-rc1-macosx.zip
Windows: http://files.arduino.cc/downloads/arduino-1.0.1-rc1-windows.zip
Linux (32-bit): http://files.arduino.cc/downloads/arduino-1.0.1-rc1-linux.tgz
Linux (64-bit): http://files.arduino.cc/downloads/arduino-1.0.1-rc1-linux64.tgz
Source: http://files.arduino.cc/downloads/arduino-1.0.1-rc1-src.tar.gz
Of course, if you have Teensyduino, this is used for Teensy even on 0022 and 0023.
If you delete any of the .d files from the temporary build directory, it will force that .o file to be rebuilt. If you haven't already, please give the release candidate a try.
I'd probably just reuse the existing parser that preprocesses the .pde / .ino files to extract a list of the #includes from all .cpp files, as if they'd been in the user's sketch. But if there's something special it should do, please enlighten me?
That really worries me, because I've run into several cases where perfectly valid C/C++ code in a sketch
will not get past the IDE parser.
I'm imagining using the existing parser only to read the .cpp files, not modify them. If it gets confused, the worst case result is a #include is not seen. At least that that's the idea.... but I honestly have not yet worked on this, so I can't say for sure.
The "something special" might be that if a library referenced another library then that referenced library
would need to be added to the list of libraries. But maybe that falls out when the same parser is used.
Yes, recursive scanning might be needed if a library depends on another which in turn depends on others.
Circular include dependency might need to be detected and handled gracefully (not an infinite loop until the JRE eats up all available RAM).
If anyone really feels strongly about this, the java code is all open source. This issue has been talked about over and over, but ultimately it's only going to be solved when someone actually does the work and submits a patch. Anyone with some java skill can do this, since the parser, list of files and compiler object are already there. It's "just" a matter of parsing all those .cpp files and adding to the existing lists, with the caveats mentioned above, and maybe other minor details I've glossed over or not anticipated.
This is issue 236, by the way. If anyone does create a patch, that's the place to post it.
http://code.google.com/p/arduino/issues/detail?id=236
Since it's already a well recognized issue, odds are pretty good such a patch might actually find its way into Arduino in a fairly short time (eg, under 1 year).