Integrate support for arbitrary architectures in brickstrap itself.

ev3dev / brickstrap

Tool for bootstrapping Debian and creating bootable image files for embedded systems

MIT License

35 stars 26 forks source link

Integrate support for arbitrary architectures in brickstrap itself. #27

Closed cmacq2 closed 8 years ago

cmacq2 commented 8 years ago

With this change brickstrap can take advantage of the work done to support other architectures besides 'arm'.

For reference see: Discussion: issue #18 https://github.com/ev3dev/brickstrap/issues/18 Implementation: PR #21 https://github.com/ev3dev/brickstrap/pull/21

Additional changes:

Fix display of exclude list in output to include a newline (without adding it to the actual exclude list)

Note: this change does not address updating the ev3dev board directories/example projects.

cmacq2 commented 8 years ago

Tested this with an example project of mine. Note that in order to test this change you need to update your project as follows:

Convert each call to ${CHROOTCMD} to use br_chroot instead
Likewise: convert each ${CHROOTBINDCMD} to use br_chroot_bind instead
Unlikely but possible: convert each ${USER_UNSHARE} to use br_unshare instead
Convert each instance of $BOARDDIR to use $(br_project_dir) instead.

This probably amounts to updating your config, multistrap.conf and hooks.

cmacq2 commented 8 years ago

How about this new version?

cmacq2 commented 8 years ago

There was a bug in option parsing causing validation to be skipped and also on reflection QEMU_STATIC should probably support the architecture mapping mechanism as well.

... I've amended the PR accordingly.

I've also added appropriate 'getter' functions, and use those inside create-tar as well.

dlech commented 8 years ago

The command line parsing seems to be working as expected now. I'm going to run through a full build to see what happens.

cmacq2 commented 8 years ago

A note on BR_QEMU, actually I would prefer not to rename it to remain consistent with BR_PROJECT and BR_COMPONENTS which are similar (the raw -p and -c option values).

It's probably easier to remember this way:

getter functions to get the sane/sanitised paths (br_project_dir/br_get_rootfs_qemu/br_get_host_qemu)
BR_ variables to hold raw values.

dlech commented 8 years ago

Alright. That's fine as long as we start a doc that explains what the common variables and functions are that one might want to use in their hooks.

cmacq2 commented 8 years ago

Which should probably be done concurrently with the necessary readme updates... ... By the way, did your test succeed?

dlech commented 8 years ago

The build looked good (other than I forgot to update the hooks like you told me to the first time around). I've pushed this along with my changes.