Building Maple IDE from git source

LeafLabs Garden » Support » Maple IDE Support

Building Maple IDE from git source

(18 posts) (5 voices)

Started 2 years ago by mlundinse
Latest reply from feurig

12 Next »

mlundinse
Member

I have been trying to setup and build the Maple IDE from the git source repository.
My main reason is to get the latest changes in libmaple and also to use an updated toolchain.

After some fiddling around I got it working, under Fedora 18 Linux and using a toolchain (arm-2012.09-63-arm-none-eabi-i686-pc-linux-gnu) from Mentor Graphics.

The installation scripts that moves libmaple into the maple-ide structure is broken with current libmaple, so I did that by hand, then the build has to be modified to handle the selection of different subderectories of libmaple.

Is there anyone at LeafLabs that is interested in the changes I made ? ( I am not a master of Git and patch submission )

Regards
Magnus

Posted 2 years ago #
bnewbold
Ex-Leaflabs

Hey Magnus,

I'd be interested in taking a look at it. We had internally decided to not to do an IDE release without switching to the Wiring code base and calling 'make' directly (instead of the horrible hack that is Compiler/ArmCompiler)... but that effort has stalled, and it would be really nice to push something out using the most recent libmaple.

You could send me a tarball (bnewbold@leaflabs.com) or push code somewhere public, whatever is easy for you.

Posted 2 years ago #
mlundinse
Member

Thats great inspiration :) so I will clean it a bit, the first try to get it working was a bit trial and error, and document my changes. Then I will send to you.

Regards
Magnus

Posted 2 years ago #
vstef_is
Member

Any news on this one?

I'm very interested in the latest version...

Posted 2 years ago #
mlundinse
Member

I will try to polish my changes into a shape so that it can be downloaded and test built by others. Hopefully I can push this to a git repository end of next week.

I plan to patch up the compile/build process so that it can build sketches using the exact folder structure and content that libmaple has and at the same time be able to use a newer arm toolchain. This will only change ArmCompiler.java, already a horrible hack, and perhaps some of the board definitions in boards.txt.

Regards
Magnus

Posted 2 years ago #
feurig
Member

Magnus, I cloned your libmaple midi so I could integrate my work (mostly converting from byte to packets and adding minimal sysex support) as a pull request, are you going to add the midi functionality to the ide? That would rule.

Posted 2 years ago #
feurig
Member

bnewbold,
How much community support would it take to get that UNstalled? I think the make based system is what kept me in the libmaple fold this long. It is one of the things I was excited about seeing incorporated into Wiring.

Posted 2 years ago #
bnewbold
Ex-Leaflabs
Of the top of my fuzzy head, getting the make system into the IDE would require:
- bundling compatible 'make' and dependent binaries for each platform
- writing something like ArmCompile.java which would call make with the correct environment (variables, path, files) and pass stdout/stderr back up to the IDE in the very frustrating IDE format (maybe this is easier in Wiring?)
- tweak compile setup routines to either copy the entire libmaple source tree to the temp build location, or put that tree on the include path. The existing Makefiles expect all the source files to live in particular locations
- potentially tweaking the makefile system to work from arbitrary paths
- figure out how to make all this work with IDE-level libraries
- testing, packaging, and documenting this for all platforms
Getting things to "just work" on a development machine shouldn't be hard, it's the last point that is the majority of the work and the biggest blocker.

I looked in to using ant as a library from within the IDE to execute Makefiles; there seem to be some C/C++ support plugins for ant, but nothing to call Makefiles.
Posted 2 years ago #
bnewbold
Ex-Leaflabs
feurig: do you think the IDE is even necessary any more? The toolchain situation has improved greatly, and I think if I was going to do this all over again today, i'd probably create tarballs for each platform including:
- Sublime Text or some other text editor with minimal hotkey support for building
- gcc-arm-embedded toolchain
- upload tools
- gtkterm or similar serial console
- libmaple in a subdirectory
- HTML docs
- template projects
The cognitive leap between the Maple IDE and tools like the above doesn't seem very large to me. Historically, the Arduino IDE seems to have beaten the WinAVR-style tool bundle, but WinAVR was a pain to use, didn't target specific devices, and included (IIRC) all sorts of "confusing" things like a dis-assembler, debugger, etc.

The biggest missing piece IMHO would be an easy way to select a serial port, target device, and "fileset" (files to be compiled) without needing to edit a Makefile.
Posted 2 years ago #
feurig
Member

bnewbold,

As someone who teaches this stuff I would have unfortunately have to say yes. For me I build everything from xcode and makefiles and use git extensively and wouldn't care if the whole thing rolled over and died. But for the Karaoke crowd the blue screen and the moving yellow letters is critical. I am even more interested in getting an IDE (although I would happily ditch the heavy handed java pile for something a little more lightweight) that would allow people to get started making and modifying their own midi devices.

It wouldn't take much to extend the existing maple system to allow the boards to identify themselves (why the arduino people never figured this out is completely beyond me). Though this is much more easy to implement in midi or other protocols.
I plan to spend the month of june at ITP Summer camp working on this.
http://www.suspectdevices.com/blahg/proposals/lets-get-loaded-a-midi-sysex-ecosystem-for-loading-and-debugging-code/

Posted 2 years ago #
mlundinse
Member

I have made my own single makefile without using the libmaple makefiles to build a simple main.cpp from a remote directory, then move exactly this build sequence into the ArmCompiler.java, not a pretty way to build stuff, but it works until we can run the whole make thing from the IDE. Having this structure should make it easier to move to a make based build from inside the IDE.

I got this mostly working, needs more testing though.

The usb stuff I must think about a bit since the midi and serial are not happy together due to the weakly defined global structures in the usb_lib, so sending both tothe linker is a recipy for disaster

Posted 2 years ago #
feurig
Member

I created a separate board called maple_midi and in its makefile define USB_TYPE=midi that seemed to work ok for sorting out a bunch of it. It might make more sense to define USB_TYPE and not have created a separate board but I wanted to be able to define where the hardware midi was on a per design basis.

Posted 2 years ago #
gbulmer
Moderator

feurig - have you considered NetBeans, which is relatively simple?

Posted 2 years ago #
feurig
Member

gbulmer, No I hadn't my long career as a sysadmin has given me great disdain for all things java (... but if it works well and I don't have to write it ...)

Posted 2 years ago #
mlundinse
Member

Agreed, a build flag USB_TYPE with possible values USB_MIDI and USB_SERIAL that defaults to USB_SERIAL when unset, this will play nice with both IDE based builds, where it can be set in boards.txt and makefile based builds.

Posted 2 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.