[CCC DEV] Supporting multiple platforms

[Matt Jadud]

On Fri, Jun 18, 2010 at 10:04 AM, Adam Sampson <ats at offog.org> wrote:
> can't use /usr for some reason, then it should use /opt/occam to be
> FHS-compliant.

Yeah, I knew that... but I didn't know that /opt was a compliant
option. (I missed that.) I didn't want to touch "/usr" directly,
because I didn't trust my process. At least this way I could keep
everything self-contained.

I'll flip it to /opt for the moment. I knew the package wasn't
compliant, but this is a big tire-patch. I started reading the
documentation on proper packaging, and will revisit it after this
"sprint" on the Mega to do things correctly. (I'd like a "good" Deb
package for OSCON, so this is definitely on my to-do list.)

> standard Debian package infrastructure (debhelper et al.) will do nearly
> everything you're doing by hand there anyway, so most of that can be
> migrated into a regular debian/rules file eventually.

Yep. I will do that next. The "tire patch" here is that I need an easy
way to give the students updated versions. I don't really expect this
package to ever see the outside world.

> of "avr-occbuild --program foo.occ; avr-occbuild --upload foo". The
> search path stuff you're doing in there won't be necessary once the AVR
> modules are built and installed in the standard way.

This is what I thought.

> usually better to have a top-level header that explicitly includes the
> things it needs from the subdirectories (i.e. #INCLUDE
> "platform/arduino/foo.inc").

> iom328p.inc isn't really platform-specific -- it's just an automatic
> conversion of the AVR header, and if we had two different boards that

OK. It sounds like what I've done is a step, and it's not all in the
wrong direction. Once we get Ian and Co. moving on the Mega, I'll
revisit the packaging (properly), ask some questions about
avr-occbuild (so as to update it in a sane manner), and adapt/move
header files to handle board/processor differences better.

For now, we'll leave all of this in the branch, and can worry about
whether any of it should merge back in later. Nothing was done here
that was complex/substantial/invasive, so that's fine.

Thanks.

Cheers,
Matt