dev.ed.am
Arduino Makefile
previous_open_issue.png
Go to the previous open issue
previous_issue.png
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
bug_report_small.png
icon_project.png Arduino Makefile / Closed Bug report #3 Library directory selection is too strict
action_vote_minus_faded.png
0
Votes
action_vote_plus_faded.png
next_issue.png
Go to the next issue (open or closed)
next_open_issue.png
Go to the next open issue
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue basics
  • Type of issue
    Bug report
  • Targetted for
    Not determined
  • Status
    Closed
  • Progress
  • Priority
    Not determined
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (1)
People involved
Times and dates
  • Posted at
  • Last updated
Issue details
  • Resolution
    RESOLVED
  • Reproducability
    Always
  • Severity
    Normal
Attachments (0)
There is nothing attached to this issue
Commits (0)
There are no code checkins for this issue
Duplicate issues (0)
This issue does not have any duplicates
Description
The arduino IDE automatically includes a library in the build (i.e. builds it and links against it) if *any* header in the root of a library's directory is #included. So, for example, you can have a library directory called foo which contains bar.h and going
<source lang="c++">#include <bar.h></source>
would automatically include the foo library in the build.

The makefile's logic is slightly different. It only automatically includes libraries only if the included header has the same name as the library directory. So in the above example, the foo library would not be included. This logic needs to be made more compatible.

The IDE's logic is horrible. For example, adding a math.h to a library makes the system math.h inaccessible. And two libraries (which might have been written by unrelated 3rd parties, remember) can not have headers with the same name and both be accessible. But fortunately, the makefile's automatic inclusion of libraries is only done in the "automatic" mode, so the IDE's crappy logic can be overridden and libraries specified manually.
Steps to reproduce this issue
# use the makefile in automatic mode.
# #inlucde a header from a library where the header name is different from the library name
# observe the makefile not including the library in the build.
Comments ()
#11
 edam (edam)
Jul 19, 2013
fixed in r89

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from Confirmed to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • Information about the user working on this issue has been changed, from edam to Not being worked on.
#8
 edam (edam)
Jul 19, 2013
I've thought of a simple solution...

I'm going to implement the horrible behaviour of the IDE (since the makefile *is* supposed to be a drop-in replacement for it, afterall). But, if set, I'll make the LIBRARIES variable override the automatic library selection. That way, even in automatic mode, a developer can specify which libraries they want if they need to.
#7
 edam (edam)
Jul 18, 2013
Having read through the IDE code, it seems that the behaviour of the IDE, which we're talking about mimicking here, is as follows:
  1. obtain a list of all library directory names (i.e. the names of directories in the library directory, e.g., "Wire", "GSM", etc.)
  2. sort these alphabetically
  3. for each library directory in turn, obtain all top-level header files
  4. for each header file in turn, add a mapping for the header file with its path stripped to the library directory it came from, overwriting any previous mapping for a header file with the same name
  5. do the above with the main libraries folder, and then again with the sketch's libraries folder
  6. use the mappings to try to pull in a library directory whenever a header is #included in the main sketch
So the up-shot of that process is that, for any header file, the greatest named (alphabetically speaking) library containing a header of that name will be used. And sketch libraries override main libraries. So this would explain why #including Wire.h pulls in the Wire library, and not the Robot_Control library, which also contains a Wire.h.

This behaviour is quite obviously extremely fragile and seems rather ill conceived. I can imagine a variety of situations where it might lead to problematic behaviour. For example...
  • adding a header to your library can prevent other libraries from loading (e.g., a Wire.h in your new "Zebra" library will prevent the Wire library from working)
  • using two third-party libraries in the same sketch that happen to both contain some header with the same name will result in only one working (so are all third-party library developers are expected to co-ordinate the names of their headers so as not to have any naming clashes?)
  • using a third-party library that happens to contain a header with the same name as any header in any of the main libraries will probably prevent the main library from working (so are all third-party library developers expected to test their library in combination with every main library?)
  • the Robot_Control library can not (apparently) be used at the same time as the Wire library, as they both contain a header with the same name, despite them both being regular libraries shipped with the Arduino 1.0.5 software
The single reason to implement this behaviour would be for compatibility with the IDE. But, for the reasons above, my instincts are strongly against implementing it. So I am quite interested to discover some examples of situations where not mimicking this behaviour leads to a problem and also, then, in trying to figure out how common/widespread such problems might be. I have no desire to cause incompatibility, but if the degree to which not implementing this will cause problems is relatively insignificant, there might be case to justify it.

History