Yes the update can prevent rebuilding of certain files for a given sketch under certain circumstances,
but since the IDE doesn't build core or Arduino library archives and store them independently of IDE sketch build area,
the IDE must rebuild library archives when say changing board types or restarting the IDE.
Make, ant, or other build tools can't reuse code between board changes either. The Arduino core and most libraries contain MANY #ifdef checks on the processor and clock frequency. When you change to a different board, all that code simply must be recompiled.
Depends on how it is implemented. If the build system creates a library archive for each board type,
the library code for that board type is only ever built once or whenever the library code changes.
There could also be an implementation where Arduino libraries are "installed".
Where at install time, the library code is then built for all board types and archived into the appropriate library archives.
The Arduino IDE could be updated with all the "smarts" to do this kind of stuff as well
so it is more of a build methodology issue than a specific tool issue.
Compiled code is indeed not saved between IDE sessions. Is that really a big deal? Really?
I agree that it is not that big of a deal. I even stated as much earlier. I was simply pointing out (in a long winded fashion)
that the IDE even with the additional smarts is still not quite fully doing what Pico was wanting/asking for
as even with its additional smarts it still sometimes re-compiling modules that have not changed.
(For the record, I didn't think the dumb way of building everything every time was that bad)
But in the bigger picture I wish if the IDE were not going to really do things "right" with dependencies
then I kind of wish it would even be simpler/dumber and simply glomb everything together into one HUGE compile unit rather
than to try to pretend to deal with things like library archives.
Compile times wouldn't be any longer than what was being done before the "smart build" updates, and
if everything were glombed together there are other compiler optimizations that could be done.
For example, it would be possible to crush down things like digitalWrite() into single instructions
as the compiler could now have visibility into all the mapping tables. This would allow getting the optimized
AVR bit set/clr instructions when using constants without having to resort to using separate matching macros to map things
Long ago, Arduino compiled code to an "applet" subdirectory within the sketch. The change to using a temporary directory was primarily motivated by Arduino's usage in schools with tightly locked down systems. One of the few places you can be absolutely certain is writable under even the most strict security is a temporary directory.
I'm familiar with that and understand why they did what they did.
I don't necessarily disagree with it given the state of the rest of the IDE build process, but
I believe that there are some other alternatives like creating build areas under users sketchbook area
that offer the potential for more advanced/smarter capabilities.
An Arduino library being able to call another Arduino library is very problematic with the current IDE build methodology. Yeah, there is a hack to allow it to work today, but it involves adding header files to the actual user sketch
This is issue #236. I will fix it. I would have fixed it about 6 weeks ago, had David not temporarily changed his mind on this issue.
... what concerns me more is that certain things like conditional compilation, (sketch being able to control compilation options of libraries), libraries being able to call other libraries, library code being able to detect and conditionally change based on board type (not processor type, or having to poke around for "magic" defines), being able to source level debug are the killers.
Are you sure that's it? I mean, really, if these things were all fixed, I have a strong feeling you and many, many others who don't like the IDE still wouldn't like it.
I'm sure there are LOTS of other little things you and many others will name as Arduino IDE deficiencies once all this stuff is fixed. The simple fact is Arduino is designed to be simple and NOT have lots of advanced options. There are always going to be lots of things present in AVR/Atmel Studio, Eclipse and Visual Studio that won't be in Arduino
But I don't believe that
"Simple" has to preclude eliminating advanced capabilities.
I'm not a whiner. What I do tend complain about is when ease of use simplifications come at the expense of restricting
or even precluding more advanced functional capabilities,
especially when it is do to implementation/design decisions that really don't impact the simpler
uses or cost additional resources to implement.
For example, in some situations you can go down path A or B and neither affects high level usability
or ease of use but perhaps one make its easier or harder to do more advanced things.
This is some of the things I've seen in Arduino not just in the IDE but also in some of the core libraries.
I draw a clear distinction between the IDE and the Arduino software environment.
From my outsiders point of view, the Arduino teams vision doesn't seem to include much thought about this distinction.
It seems to be very much everything "Arduino" and the IDE and the s/w environment (core code and libraries)
are all seen as one.
So there doesn't seem to be much thought given to making the s/w environment more friendly to more advanced users
or users that wish to do Arduino development but perhaps not with the IDE.
In other words take a look at issue #236. It is a great example that shows how things are inter related.
If there were a board type Arduino library archive created for all the "installed" libraries
there would be no issue trying to figure out which libraries to link in. You could simply
add the top level libraries directories to the include path which would allow each library to locate other libraries
header files by using #include <libname/libheader.h>,
then link against the Arduino library archive for the currently selected board type.
So things come back full circle.
If the build methodology created board type Arduino library archives, not only could unnecessary
compiles be avoided, but it also makes things like linking in library code and handling sub library
Not that it has to be done that way, but just an example how things are inter related and how
things cascade by certain decisions in the build methodology.
For me, is isn't so much what the IDE does or doesn't do. It is more the build methodology and
what it prevents or makes difficult, whether that is using the IDE or not using the IDE.
So for example, I think all the talk about building/rebuilding objects is pure noise.
That kind of stuff is not a functional issue. It does not prevent or preclude anything from being done.
(Makefiles can be written to be just as dumb)
However, look at a few of some of items the advanced users are wanting:
- libraries calling other libraries
- ability to easily identify board type at compile time
- ability to change/modify compile/linker options
- ability to set compiler defines on a per board type basis.
- ability to do source level debugging
- enable floating point libraries, like printf()
- better/new define names for pins to avoid having to detect and adjust code based on board types.
Those are functional issues. And currently the only way to make many of these work
is to either to modify the IDE or jump to something like your own Makefiles.
MPIDE handles several of these things much better in this area than the Arduino IDE as you can, if you choose, have more control
over the compile & link parameters all the way down to the board type level.
So overall I do wish there was a bit more thought going on about the Arduino s/w development
build process to ensure that things are easier for building more complex Arduino projects.
And just because the project is more complex doesn't mean that this advanced capability is
directly exposed to the end user or that it is more complex for the novice user
to build it or use it.
But I do agree, source level debugging is the big issue. Of course, it's an absolutely non-starter with AVR. Atmel absolutely will not provide the debug specs for their AVR chips. Nobody, other than Atmel, can reasonably work on this (short of impractical reverse engineering) as long as AVR is the platform.
Not necessarily. You can do it purely in software without having to deal with any of their
debugging hardware or interfaces. I know how to do source level debugging using only a serial port with gdb on the AVR.
It does require stealing a hardware pin to steal an interrupt,
and a very small (hundred or so byte support code monitor) but it can be done.