Does anyone maintain this project anymore?

[dpc]

Anyone willing to fork and take care of if not?

[nkrkv]

Well, it is not abandoned. It is updated in rare, short, but intensive bursts.

The next sprint is scheduled on the beginning of April.

[prologic]

I'm interested in using this tool for my Tiny Duino based projects. I hope this project will remain somewhat active :)

[prologic]

Would the owner/maintainer of this project care to comment on this issue? I'm a 12+ year strong backend devops python developer and since I'm just getting into Arduino projects via Tiny Circuits' Tiny Dunios I'd be interested in helping this project out since I'm very much a UNIX as an IDE kind of developer and would value the longevity of this particular project!

[nkrkv]

Well, as far as I understand Arduino IDE 1.5.x has slightly changed an architecture to be much more flexible. It's easy for 3-rd party developers to add support of new “unofficial” hardware. The deal is just to create few directories and ini-style files. Ino will support this. So if you can work with Tiny Duino from Arduino IDE you would do the same with ino. That's the main point: ino should be a strict superset of Arduino IDE build pipeline.

[nkrkv]

And, I haven't reviewed pull requests, but it is very likely that I'd merge them to master if they have decent quality. Last sprint a couple of requests was accepted as is. And I thank developers for that contribution.

[michaelsproul]

I sort of forked Ino.

Actually I rewrote something similar from scratch. Its not as fully featured, but its simplicity lends itself well to modification. Once the Arduino 1.5.x IDE is released (and the spec finalised), I'll update it to work with it.

https://github.com/gnusouth/xuino

[prologic]

How does yours differ from ino? What features does it have? Is it written in Python?

Also on another note, I'm only interested in CLI-based development tools for Ardunio that do not depend on the Ardunio IDE itself.

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

On Fri, Mar 21, 2014 at 9:25 AM, Michael Sproul notifications@github.comwrote:

I sort of forked Ino.

Actually I rewrote something similar from scratch. Its not as fully featured, but its simplicity lends itself well to modification. Once the Arduino 1.5.x IDE is released (and the spec finalised), I'll update it to work with it.

https://github.com/gnusouth/xuino

— Reply to this email directly or view it on GitHubhttps://github.com/amperka/ino/issues/156#issuecomment-38233184 .

[michaelsproul]

Rather than using Makefiles behind the scenes, Xuino gives you a Makefile that you can customise. The makefiles are simple, because the variables are filled by calls to Xuino. For example, to get the list of directories containing relevant headers, Xuino's makefile contains a line like this:

HEADER_INCLUDES ?= $(shell xuino get src $(LIBRARIES) --board $(BOARD) -I)

This variable is later used as an argument to gcc (the -I prepends a -I, for "include header" before each directory).

avr-gcc -x c++ $(CFLAGS) -c -o $@ $< $(HEADER_INCLUDES)

It also resolves dependencies on a library by library basis. It knows that the entire Ethernet depends on the SPI library, and will compile the SPI library if you're using the Ethernet library. Ino, on the other hand, resolves dependencies on a file by file basis, and has problems with files with the same name (even if they are in different libraries, see: #134 ). Due to the small number of Arduino libraries, and the ease with which new dependencies can be added, I think my approach is more robust.

And yes, it's written in 100% Python 3, and doesn't require the Arduino IDE at all.

[prologic]

Sounds interesting... I'll definately look into this when I get home :)

Thanks!

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

On Fri, Mar 21, 2014 at 9:47 AM, Michael Sproul notifications@github.comwrote:

Rather than using Makefiles behind the scenes, Xuino gives you a Makefile that you can customise. The makefiles are simple, because the variables are filled by calls to Xuino. For example, to get the list of directories containing relevant headers, Xuino's makefile contains a line like this:

HEADER_INCLUDES ?= $(shell xuino get src $(LIBRARIES) --board $(BOARD) -I)

This variable is later used as an argument to gcc (the -I prepends a -I, for "include header" before each directory).

avr-gcc -x c++ $(CFLAGS) -c -o $@ $< $(HEADER_INCLUDES)

It also resolves dependencies on a library by library basis. It knows that the entire Ethernet depends on the SPI library, and will compile the SPI library if you're using the Ethernet library. Ino, on the other hand, resolves dependencies on a file by file basis, and has problems with files with the same name (even if they are in different libraries, see: #134https://github.com/amperka/ino/issues/134). Due to the small number of Arduino libraries, and the ease with which new dependencies can be added, I think my approach is more robust.

And yes, it's written in 100% Python 3, and doesn't require the Arduino IDE at all.

— Reply to this email directly or view it on GitHubhttps://github.com/amperka/ino/issues/156#issuecomment-38234504 .

[prologic]

@gnusouth You got an IRC Channel for your xuino project or on IRC at all? I'd love to get up and running with a full development environment using xunio tonight (+10 GMT) and starting a) Hacking at my TinyDunio projects and b) Contributing to your xuino project!

[michaelsproul]

@therealprologic I'm pretty new to IRC, but I just set up #xuino on irc.freenode.net

Sorry it wasn't ready last night (I'm also on the east coast of Australia).

[prologic]

No problems! OSS is never about doing anything to a schedule :)

James Mills / prologic

E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au

[prologic]

@nailxx Thank you very much for updating this Issue and confirming that this project (Ino) is well and truly active and maintained and backed by a commercial company that utilities Ino itself!

I got Ino and all required dependencies up and running last night for my TinyDuino boards very easily!

https://bitbucket.org/prologic/ledsweep

@gnusouth I'm terribly sorry about our conflict and failure to resolve our differences. I guess I feel just as strongly about standards and best practices as the next developer. Problem is "everyone has their own standards". Sorry we couldn't collaborate! I've chosen Ino as my tool of choice since it's a) Well supported b) Uses best practices and standards and c) "Just Worked".

[ivankravets]

Earlier I've asked about integration with Energia Project (issue #162). But didn't receive any answers.

In this situation I created a cross-platform code builder and the missing library manager named PlatformIO. It can build not only Atmel AVR code, but also TI MSP430 and TI Tiva and has built-in library manager.

If you prefer Wiring Framework you can build single code for these 3 embedded platforms using single command:

    $ platformio run

See example here.

Sure, it supports latest Arduino 1.5.+!

[dmr]

So, do I read correctly: ino is basically unmaintained and @michaelsproul created xuino to rewrite broken components?

[michaelsproul]

@dmr: Kind of. Xuino is essentially unmaintained now too. Creating third-party Arduino build tools is quite a lot of work due to the ever-changing upstream Arduino tools. I became particularly disheartened when I saw the plethora of features offered by the 1.5.x releases,. Arduino 1.5.x makes third-party tools more or less obsolete, as well as more time-consuming to create and maintain. I haven't actually done any Arduino programming since July, but when I last checked the upstream distribution, they were starting to offer a command-line build tool (called arduino). If I continue with Arduino development I will probably use this tool, and submit code to the upstream Arduino repository.

https://github.com/arduino/Arduino

[dmr]

Thank you for the reply. I'll try to go with the arduino package