Enabling builds on multiple platforms

spfrc

So, with all the chatter going on about getting the firmware built on Mac, plus Julian hinting that he's moved back to a UNIX-based development environment, this suggests that it may be useful to get a build system in place that at least eases the path towards building on both UNIX(ish, let's assume Linux) and Mac environments.

Does anyone have any strong opinions about a direction for this; autotools vs. cmake vs. something else?

Asking because this is relevant to my interests, but I don't want to start on something of limited utility.

pld

Instead of fighting with Eclipse I just (literally minutes ago) wrote a makefile for the DrumSynth_FPU directory that seems to produce an output file. I'll look at the AVR part probably tomorrow. Its only been tested on my Mac but it should work on Linux. AFAIK Eclipse can import/use makefile projects, so that might be the simplest option?

CMake however would be cool to generate makefile or Eclipse projects, but I remember it being painful for cross-platform projects, let alone two separate cross-platform targets in the same project?

spfrc

Yeah, I've only thought about this briefly, but your points are interesting

• Something Makefile based could easily work.  Maintenance cost vs. something else is the main concern here
• Something which could ease both Eclipse-based & non-IDE development should be a win; I suspect there's an audience for both

btw, only mentioned cmake out of completeness, I'm not particularly a fan of it  Then again, if it allowed easy generation of Makefiles, plus Eclipse project setup, maybe that would be neat?

rudeog

I'm in favor of makefiles. For my own stuff, I'll continue to use eclipse, if only to get the context help, and the ability to easily go to errors and warnings. But the advantage to makefiles is that we don't have people struggling to get this thing building as is happening now. It looks like eclipse behaves differently for everyone (even on the same platform) and me and Julian even had some differences when he was trying to merge my stuff.

 I would be in favor of keeping it simple (eg a set of path additions and possible known env vars that a user is instructed to set which influence the build) rather than trying to get fancy with auto tools. We have two simple projects that have no external dependencies other than the avr and the arm tool chains.

pld

I've used CMake for some projects, but nothing cross-platform. It makes some things easy and it sounds really cool, but 9/10 have ended up generating makefiles anyway And as @rudeog says, we don't really have massive dependencies that have to be resolved...

Is building on Windows a (major) concern?

spfrc

Sounds like straight makefiles is the consensus then

Can't comment about building on Windows (Mac & Linux myself), but it should be possible to accomodate that environment without too many hurdles once a base setup is in place.

egnouf

I am on MAC (and may be soon I may move for Linux) but anyway, If I can compile with MAkefile, I take Makefiles :-)
I am lookgin forward to get the pld make files for MAC :-))))))

regards!

pld

https://github.com/patrickdowling/LXR/tree/makefiles

If you have avr-gcc and arm-none-eabi-gcc etc. in your path, you should just be able to run "make" in the LXR directory, or you can do something like this:

AVR_TOOLKIT_ROOT=/usr/local/CrossPack-AVR/ ARM_TOOLKIT_ROOT=~/dev/gcc-arm-none-eabi-4_7-2013q3/ make clean firmware FIRMWARE=TEST.BIN

This produces a binary for me (OS X) at least

~/dev/LXR (makefiles ✘)✭ ᐅ ll firmware\ image/TEST.BIN
-rw-r--r--  1 pat  staff   254K  1 Mai 10:32 firmware image/TEST.BIN

Caveat: My hardware isn't finished so I haven't tested the result, so possible **==

Almost forgot: you need to have the fixed \ vs. / #include paths, either from rudeog's repo or my path_fixes branch.

Good luck

edit: hm, [fixed], [pre], [code]? Never mind...

egnouf

oki, i will test during the day or tommorrow :-) big thx!

egnouf

Oki,
I catch your code (@pld) and then I noticed that I have:
- arm-none-eabi-gcc
but not the avr-gcc file in my hard disk (MAC) .

heu, did I missed something?

egnouf

oki, i think i found it (the search on MAC did not find it :-( i had to do a find . -name "avr-gcc" to find it):
- /local/CrossPack-AVR-20131216/bin/

I continue !

spfrc

pld++, excellent work!

egnouf

it is compiling :-)
I have just an issue wioth one more PATH :

    ^
buttonHandler.c:13:20: fatal error: IO\din.h: No such file or directory
 #include "IO\din.h"

I guess I forgot to include the PATH to the IO folder, no ?
what shall I add ?

thx :-)

egnouf

oki, so I think in the file "buttonhandler.c" we can still find some BACKSLAH :-(
next, it seems that this file is "non UTF8" compliant , my GEDIT shouts at me :-)
I continue to investigate and come back to you :-)

egnouf

Oki, so I found the backslah in some others files, I took the @pld code as I thought it was corrected as in the @rudeog version :-)
my fault! anyhow, I corrected the "backslah" and compiled ... it works fine now!

here is the list of files I changed:

frontPanelParser.c

buttonHandler.c

diskIo.c

din.c

adcPots.c

main.c

Presetmanager.c

///

I keep you inform on the rest...

BIG BIG tyhanks to you guys as I think I progessed on my MAC for the compilation :-)

If everything works (I will put the new firmware in the LXR memory) I will then create a short tutorial for MAC people :-)
Big thx again!!!

pld

I kept the backslash fixes in the separate branch (path_fixes) to avoid conflicts -- I think by now enough people have made those changes I was offline when I got far enough for it to matter, otherwise I would have used rudeog's version

pld

FYI: I updated with the image I built and it booted normally afterwards.

Might be useful to be able to give a custom version number for the build...

spfrc

Got this built OK on Ubuntu (12.04, LTS, don't ask  Will do test build on Mac later and verify both images on the LXR itself.

Process used

- Download of GNU bare metal ARM toolchain from https://launchpad.net/gcc-arm-embedded (v4.8)

- Download of Atmel AVR 8-bit toolchain from http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORLINUX.aspx

- Extract, set ARM_TOOLKIT_ROOT and AVR_TOOLKIT_ROOT appropriately

Notes

- Firmware builder needed an include of <cstring> for memset() (G++ 4.6.3)

- Older versions of avr-gcc (e.g. 4.5.3) will moan about "#pragma GCC diagnostic not allowed inside functions" (via https://github.com/SonicPotions/LXR/blob/master/front/AVR/front.h).  Not an issue if you use the up-to-date Atmel tool chain as that's at a version where the above is acceptable.

- if one was to go down an apt-managed route (avr-libc binutils-avr gcc-avr), there'd be some other changes to make (include paths for AVR headers etc.)

Once again, thanks Patrick; nicely done.

spfrc

Mac setup (10.9.2)

- Download of GNU bare metal ARM toolchain from https://launchpad.net/gcc-arm-embedded (v4.8)

- Download of Atmel AVR 8-bit toolchain from http://www.obdev.at/products/crosspack/download.html (CrossPack-AVR-20131216.dmg is the most recent as of 2015/05/02)

- Extract for ARM toolchain; install for AVR toolchain

- Set ARM_TOOLKIT_ROOT and AVR_TOOLKIT_ROOT appropriately

  - Crosspack for AVR installs to /usr/local/CrossPack-AVR via symlink

spfrc

Verified freshly built firmware loads from both Linux & Mac builds.  Didn't do anything other than program a simple sequence and fiddle with a few menus, but it comes up OK

pld

Great, thanks for checking.

I only have a half-working 10.04 ubuntu here which probably can't even be updated

egnouf

We oculd imagine at a certian to make a google hangleout between you, me, etc, and julian ? no?

pld

If we need realer-time communications.

In the meantime, async forum posting is probably easiest...

spfrc

Note: change to FirmwareImageBuilder.cpp for building on Linux is merged in rudeog's repo, so Linux builds are good to go from there, once the Makefile changes are merged in

julian

great work!
I'm just about to set up the build on my new Kubuntu environment (and I was never good with writing makefiles manually, coming mostly from a visual studio programming background).
I'll report back when I have succesfully build a new version here.
Glad you chose makefile while I was gone.
That would have been my suggestion as well

julian

okay. I just finished reviewing all the changes rudeog and spfrc made.
No it's time to set up the build envirenment on linux and test if it is compiling and working.

I'll try to note which packages I'll install, so maybe we can setup a script that will fetch all the required dependencies for the build.

pld

We could add a 'prepare' target to the root makefile to download the recommended compilers if it doesn't find them on the path and the env variables aren't set?

Is it worth making the "version" string configurable overrideable for private builds?

I only found it in the AVR part, I guess the assumption is that both parts are always updated together? (makes sense...)

julian

so one would have to call
'make prepare'
to get the recommended compilers installed?
sounds good.

I'm currently trying to set everything up here.
still getting the '/bin/sh: 1: /bin/arm-none-eabi-gcc: not found' error, although the compiler is in the path.
but I'm getting there


yep, both images are updated together, since the normal update process uses the combined firmware image.
Not sure if it is worth it to implement an override. since everybody who is making custom builds will probably change some source files anyway.

pld

Hm, that looks there's an issue if you don't set ARM_TOOLKIT_ROOT and rely on the path. I'll take a look and see if I did something silly in the makefile...

julian

path is set correct.
I can call
'arm-none-eabi-gcc -v'
without problems.

currently looking at your makefile, too

pld

Check https://github.com/patrickdowling/LXR/commit/9199fa7a60eb1e2ffd468fd6702df06e01b63586, I think it should work. Must have been late