aleph libavr32 migration

[catfact]

migrate aleph codebase to share libavr32 submodule with avr32-bsaed monome eurorack modules.

despite this being an enormous diff, the changes are not very complicated.

• the old avr32_lib has been removed and largely replaced with the libavr32 submodule
• aleph-specific sources from avr32_lib have been moved to avr32
• added aleph_avr32_src.mk and aleph_avr32_config.mk for application boilerplate
• edited some include statements in application code.
• added .clang-format. this hasn't been applied yet...

merging with the development branch might be an adventure... one step at a time.

the point of this exercise is to be able to share module code more easily. in the near term, that means backporting some improvements and additions like keyboard and MSC drivers, and maybe a better FAT filesystem. in the longer term, we may be able to more freely share bigger chunks of functionality.

[ghost]

So @catfact as discussed in the lines thread:

http://llllllll.co/t/aleph-refactoring-and-integration/5130/34

If those new grid-ops are merged, then all my work from the last year is merged into dev. I'll attempt a merge of catfact:aleph-libavr32 into dev, try and get a sense of the difficulty...

[ghost]

OK so only a handful of conflicts when I tried to merge from rick-monster/raw-grid-ops catfact/aleph-libavr32 (although it did send my emacs a bit crazy!)

only problem is after the merge bees won't compile. So I checked out catfact/libavr32 & can't even get BEES compiling on that branch (maybe the merge is absolutely fine)! Steps to reproduce this problem:

checkout remotes/catfact/aleph-libavr32
cd ~/git_checkouts/aleph
git submodule init
cd apps/bees
make

Makefile:31: ../../libavr32/asf/avr32/utils/make/Makefile.avr32.in: No such file or directory
make: *** No rule to make target '../../libavr32/asf/avr32/utils/make/Makefile.avr32.in'. Stop.

Am I missing some totally basic thing about how git submodules work? (probably, yes!)

[catfact]

oh, well one thing about submodules is that you need git submodule init to set up the submodules and then git submodule update to actually fetch their contents.

i just checked it again with a fresh clone.

one weirdness comes from the fact that the necessary updates are in my fork of the libavr32 submodule but they are not upstream. but i don't want to commit changes to .gitmodules to point at my fork.

so this is the whole clumsy song and dance that resulted in a functioning tree (surely not optimal but my git-fu is limited)

git clone https://github.com/catfact/aleph.git
cd aleph
git fetch --all
git checkout -b aleph-libavr32
git merge origin/aleph-libavr32
git submodule init
git submodule update

now git complains because the submodule doesn't know about my fork and so doesn't have the commit that i asked for. so:

cd libavr32
git remote add catfact https://github.com/catfact/libavr32.git
git fetch --all
cd ..
git submodule update

and now i can build bees.

[ghost]

that's bananas! Really hoping for a sudden moment of enlightenment on these submodule shenanigans - I'll try tonight...

[ghost]

ok so the crazy submodule magic worked out for me in the end...

Merged into my other pull-requested branch relatively painlessly here:

https://github.com/rick-monster/aleph/tree/libavr32.merge.new-gridops

just a couple of changes to get BEES building again:

https://github.com/rick-monster/aleph/commit/e9179bb0124bc37e8ee5601dad7d120d9f979322

So pretty sure there will be no merge conflict hell merging this change into master, then rebasing or merging dev on top of that!

don't think serial will quite work again without migrating this change forward into the new avr32lib:
db57cab

I'd prefer to jump straight to testing on a dev + aleph-libavr32 merge so we can use serial protocol, seeing as the technique was so effective for BEES memory management changes. Anyone else, thoughts on testing?

[catfact]

closing this cause all these commits are in the big PR