-
Notifications
You must be signed in to change notification settings - Fork 232
Ino picks wrong dependency #134
Comments
got bit by this too, this time for Robot_Control/Wire.h vs Wire/Wire.h |
the wrong dependency list is being generated by avr-gcc it looks like. This is because it's being given an over-broad include path, and avr-gcc just grabs the first match it finds.
Perhaps the solution is to allow the user to specify their own include paths. Just adding everything like that (besides core) seems like a recipe for trouble I was able to work around this by applying this diff --git a/ino/commands/build.py b/ino/commands/build.py
index 7aea046..df9fffe 100644
--- a/ino/commands/build.py
+++ b/ino/commands/build.py
@@ -275,7 +275,6 @@ class Build(Command):
scanned_libs.add(lib)
self.e['used_libs'] = used_libs
- self.e['cppflags'].extend(self.recursive_inc_lib_flags(used_libs))
def run(self, args):
self.discover(args) and passing |
I've written an Ino-like tool called Xuino that handles this correctly. It considers libraries as folders, and allows the user to manually specify dependencies between them. |
mwhooker, I think it's not the right patch to fix this issue. The Wire.d file (dependencies) still contains Robot_Control/twi.h as a path. |
I'm trying to compile a project that does an
#include <SPI.h>
.In the dependency scan, ino picks the wrong library:
$ find /usr/share/arduino/libraries -name SPI.h
:R
comes beforeS
, so ino concludes Robot_Control is depended on.Maybe ino should issue a loud warning if two libraries expose the same header name.
The text was updated successfully, but these errors were encountered: