Someone interrupt me if I'm going off the rails and getting away from the purpose of Ino -- but it would be helpful if Ino did not explicitly require 'lib' but could also handle '[Ll]ibraries' (and 'Ss]ource' instead of 'src', because, why not!). This would allow some flexibility for the Arduino IDE to be able to compile and upload code structured for Ino (for cases with an *.ino file such saved under: /src/project-name/project-name.ino).
For this purpose, the Sketchbook path within the Arduino IDE could be set to the 'project-name' folder, and the Arduino IDE should correctly process dependencies in the 'Libraries' folder. This would be helpful when (1) working with team members that only use the Arduino IDE, or (2) Ino may not be able to upload code to the board as reliably as the Arduino IDE. I had both of these issues on a project with a board where the external reset was essentially inaccessible, and switching back and forth between Ino and the Arduino IDE was obviously cumbersome.
Someone interrupt me if I'm going off the rails and getting away from the purpose of Ino -- but it would be helpful if Ino did not explicitly require 'lib' but could also handle '[Ll]ibraries' (and 'Ss]ource' instead of 'src', because, why not!). This would allow some flexibility for the Arduino IDE to be able to compile and upload code structured for Ino (for cases with an *.ino file such saved under: /src/project-name/project-name.ino).
For this purpose, the Sketchbook path within the Arduino IDE could be set to the 'project-name' folder, and the Arduino IDE should correctly process dependencies in the 'Libraries' folder. This would be helpful when (1) working with team members that only use the Arduino IDE, or (2) Ino may not be able to upload code to the board as reliably as the Arduino IDE. I had both of these issues on a project with a board where the external reset was essentially inaccessible, and switching back and forth between Ino and the Arduino IDE was obviously cumbersome.
Maybe I'm just describing an edge case...?