Re: [sprint] openembedded / dpkg-cross-buildpackage hybrid
On Tue, Nov 30, 2010 at 9:49 AM, Jeremiah Foster
<jeremiah@jeremiahfoster.com> wrote:
>
> On Nov 22, 2010, at 21:04, Luke Kenneth Casson Leighton wrote:
>
>> ok - enough! thoughts anyone?
>
> Truly fascinating reading. Thanks Luke. I don't have the competency to comment as yet, but hope to learn more about OE and can maybe then comment.
appreciated jeremiah.
i've not had a response from openembedded yet - perhaps someone else
might like to pick up on this and make contact? certainly it would
help if someone from the OE team attended the debian sprint, if this
idea is considered to be worthwhile.
if you're seriously considering looking at it then i recommend that
you just... "do". build a random qemu-arm or qemu-x86 angstrom gpe
image from scratch, for example, and then attempt to add a simple
package. from simply watching the build tasks run by you actually
learn quite a bit, but definitely by adding a package, running into
errors, you get to find out far more.
i think it's worthwhile mentioning a bit more about what i've been
able to ascertain that bitbake is - you can bear this in mind whilst
playing with it, and it will begin to make sense:
a) bitbake is _not_ tied to openembedded. you could throw away all
the openembedded bitbake files and start from scratch, entirely write
your own tasks. however you lose a lot of expertise and info that
way!
b) ultimately, the job of a task is to output a shell script which
has "do_{taskname}" appended _right_ at the bottom. its execution is
logged; its success or failure results in further decisions.
c) there are both VERTICAL decisions AND horizontal decisions, all
customisable from the bitbake "task" files. by vertical and
horizontal, i mean that "vertical" decisions means inside one package,
the execution of tasks are dependent on each other; by "horizontal"
decisions i mean that *package* building is dependent on each other.
"vertical" corresponds to the debian/rules make target dependencies;
"horizontal" corresponds to the Debian "Build-Depends:" concept.
there's also a corresponding concept for Debian "Depends:".
d) there is infrastructure inside bitbake to work out the horizontal
(build) dependencies but bitbake is also aware of the vertical
dependencies! so, one package will get up to the "download and
unpack" stage, but will not run the "configure" stage until all of its
build dependencies have been unpacked in the "staging" area! and
whilst the "configure" is allowed to proceed, simultaneously the build
dependencies "packaging" and rootfs installation will also proceed.
it's really really neat stuff :)
e) the bitbake files themselves are this incredible mish-mash of
variable declarations, shell-script environment variable declarations,
shell script functions and python function declarations. the python
functions obviously cannot be executed in the shell script! but they
can be utilised to change or add dependencies, and a hell of a lot
more. it's also worthwhile pointing out that shell script and
variable declarations can have "escape sequences" in them - both of
other shell/variable declarations _and_ - incredibly - python code
fragments. typically the python code-fragments are utilised to create
complex dependencies, change the location where source code is built
by parsing the version number of the upstream package being downloaded
etc. etc. this is done quite a lot in the Gnome packages due to the
regularity of the ftp site filenames.
f) there is a lot of conceptual similarity between buildd and bitbake
- perhaps buildd _can_ be adapted to do cross-compiles...
Reply to: