Jantje:
I do not agree that it is better to treat all libraries as real libraries. The main reason is the extensive usage of defines. As the libraries in many cases can/will change (for instance because you select another arduino board.) rebuilding is the way to go.
The biggest thing that treating all libraries as real libraries will do is force the IDE developers to look
at things just a little bit differently.
The way the IDE does its build now, you pay the price for separate module compilation,
without gaining the benefits like the ability to avoid re-compiling modules that have already been compiled.
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 form 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.
--- bill
With respect to rebuilding library modules:
To handle different "board" types, that is easily handled with sub directories
or different archives names in the build area based on board type.
If a board type is changed and the library archive for that board type does not exist it would be created.
But after that first time, it won't have to be built again.
Switch board types back to a board you were just using, and the library archive for that board type
will be up to date so no rebuilding is necessary.
When archive member (individual .o files) dependencies are in place,
if the archive member inside the archive does not exist or is out of date,
rules can indicate how to rebuild that archive member. (which will create the archive if it didn't exist)
Also, if any define that affects compilation is changed (which requires editing a file),
the corresponding modules will be re-compiled, then since the module's .o is newer than the one in the archive,
the .o in the archive will be updated.
Library archives are really nice, once everything is in place to use them.
Compiler optimizations that can be accomplished by using real libraries will be minimal as libraries in arduino are typically very dedicated. In other words: "If you use the library you need all of it".
I didn't follow the comment.
Using libraries, isn't about compiler optimizations, it is merely about organizing what is compiled
and how it is linked in.
This complexity has to be added for the arduino library or your project will literally explode. (It is hard to get something on a Uno)
So there is little benefit in adding this complexity dynamically for other libraries.
Huh? I didn't follow this.
Whether you link against libraries or against individual .o files, the final linked image does not change.
All the sames things can be done with .o file or library archives.
Libraries are simply a convenient and compact way to organize and store .o files.
A library is nothing more than an archive file of .o files.
bperrybap:
In fact with proper compiler options, there is no need to do the silly file copying that the IDE is doing
for the library source files.
All compilers have a folder where you have your output files. In my humble opinion there are 2 reasons why the Arduino IDE uses temporary folders.
- to be able to separate output by build. In other words it is to much work to write code to manage the compile output. which is typically done by a compiler)
- Files can be build without saving. In other words you need 2 locations to save the file.
[/quote]
I was not arguing against using a temporary build area and sub directories.
I think having a build area is the way to go.
I was saying the copying of the source files to this build area should not necessary.
It should be possible to compile the code with the source files in place
and redirect the output objects to the very same place they are currently are.
(avoid the copy of the source files)
bperrybap:
The IDE is great example of why make and makefiles are so useful and better at doing builds.
The ideal would have been to build the IDE on top of make so that the all the IDE has to do is
build a stub sketch makefile and then let the make and a primary makefile handle all the rules for the actual build.
This would have allowed making tweaks to the build process without having to modify the actual JAVA code.
I agree on this. However I don't know how easy it would be to hide all the makefile complexity in the way the Arduino IDE does a great job now. I'm thinking about explaining "make clean" to a novice.
[/quote]
There shouldn't be a need to explain things like "make clean" to a novice.
The end user using an IDE on top of make should not see anything different from what they see today.
Make is used under the hood for its rule based build capabilities.
All the user would see different is that sketches would build much faster since
only the modified files would be re-compiled instead of all the files.
This is what other systems like Atmel's Visual Studio do.