Yep, I've been using it for quite some time.(I liked the promotional video).
I'm very happy to see the Arduino team finally accepted it for the standard release.
Any proposal to store compiled archives must carefully consider the restrictive shared network filesystems which are used by many academic institutions. A patch which returns Arduino to the "bad old days" of writing within its own directories is certain to be rejected.
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.
Every time a new IDE session is started, since it gets a new build area, then the process starts clean.
But it would allow the library archive to expand during the IDE session.
For example, since the build directory does not change when you change sketches, then the core.a
and the library{boardtype}.a files would still exist and any libraries already compiled for that board
(even for a previous sketch during that IDE session) would not need to be compiled again.
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.
In other words pay the library build time only on the first build (which would be a bit longer since it would build all libraries)
but then for the life of that IDE session builds are much faster even when you change sketches.
The library and core source files are never copied to the temporary build directory. Only the sketch source is copied, and for good reason...
I stand corrected on this. (Not sure how I overlooked that)
I had thought all the full tree for each library library was copied, but it does not appear to copy the sources.
It does seem to create a "utility" directory in each library directory even when it is not used for the library.
Does the IDE currently use the .d files it creates?
(I assume it must use them with the Teensyduino "smart build" update?)
More importantly, as the Dr pointed out in the OP,
the way the IDE works, you are stuck having to add includes to the main sketch
in order to get the include path setup to allow other modules to compile.And that is the main thrust of the the Dr's comment in the OP.
It was that in order for a module to use any
code from a library, the main sketch must include a header file from that library
to get the IDE to do some "magic" things and set up the include path.I have often considered writing a patch to fix this. It doesn't look like anyone else is ever going to do it....
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've had to alter the sketch code to get it to build.
There are also cases where the IDE appears to have some magic code to allow setting some defines inside the sketch.
It appears that because of this it looks for things and where to insert the includes.
In many of my sketches, it often screws up where to place the includes especially if there are ifdefs.
There are also simple things like a missing double quote on a string that will cause the IDE parser to crash
and you get no error message like you would with the real compiler making the error difficult to locate.
I'd be ok with sharing the parser with the library code but I think the mainline parser needs some
updates before I'd feel comfortable running all the library modules through it.
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.
--- bill