Multiple ino files don't get packed in one ino file.
Ino files do not have the Arduino preprocessor adding the function descriptors.
The fact that Multiple ino files don't get packed in one ino file is a none issue in my eyes. Arduino needs to pack them to get the include folders for GCC. My plugin saves this information at import time.
- What about a variable defined in ino1, will it be available in ino2 from both compile and intellisense perspectives?
- Joining the ino files into a single temp cpp makes all functions able to call each other without need for .h public declarations?
Am I missing a point?
I share it with the world but I can not support it like the Arduino is supported
I don't understand this, sorry if I am missing something but if it works the same as the Arduino IDE you have less support. Because if it works in Arduino then it will work with your plugin. Any problems would also be Arduino problems allowing the Arduino community to do the support
my plugin is made for people with a decent level of C/C++ knowledge only
Yes I agree you make this point clearly in your faqs
just checked ArduPilot, MultiWii as far as I can see none of them provide libraries
MultiWii uses multiple pde/ino and no libs but ArduPilot uses tons of them, so does ReefAngel.
The Arduino layer I put on top of it is to have defaults for Arduino. So just like Arduino IDE is a layer on AVRDude and GCC My plugin is a layer on WinAVR. And as Arduino IDE proves: A good layer is worth a fortune.
Yes very useful but different to Arduino
Yes there will be some work to get it working in my plugin. Though nothing more than 1 hour for someone who knows what (s)he is doing
I don't think it is practical when working with an ever changing open source project to make all these changes, especially if the changes are to be checked back into Git or ano source control provider
If they would rely on libraries (which do not support pde/ino) the libraries should work out of the box
Yes good, as long as we take the time to find all the .h file names to include in the source code.
Once you go eclipse (from Arduino) you never go back
For the experts that you target I am not surprised but this is also true for both novice and expert users of other plugins such as VS and XCode
I don't understand why you think libraries will cause incompatibilities. Can you elaborate?
As long as you support both Arduino IDE and User libs it should be fine. My point wasn't very well made, I was referring to the global decision to not combine pde/ino, not to auto insert .h lib #includes for larger projects and libraries and not to include utility folders.
Your faq mentions inserting a single .h for libraries but would that work with libraries that use more than one .h? Don't we need to include all the .h files from each library folders as #includes? and support utility folder for i2c?