Openmoko build infrastructure questions
andy at openmoko.com
Wed Apr 16 21:15:00 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| OE is a powerful build system, but it's quite different so it can be
| hard to learn.
| If you know how to use OE, develop with it can also be easy, too.
| Here is how I do it. I believe there are others using similar ways.
Sure. Somebody mentioned "six month learning curve" on IRC once.
| # compile for the first time to get the run.do_compile script.
| bitbake helloworld -c compile
| So, in my point of view, this discussion is meaningful only if someone
| can provide another build system that has the same or better ability
| then OE, yet easier to learn, and the switching cost is acceptable.
WHY is what we are doing so DIFFERENT from what normal desktop distros
set out to provide that we need "a powerful build system, but it's quite
different so it can be hard to learn". Why do we need that handicap of
a special "hard to learn" stumbling block for anyone that wants to
contribute? What is it doing for us that can't be done with a normal,
existing, well maintained normal distro with a lot of users who know how
to package and so on already?
"Cross build" is the only answer I understood.
| Otherwise the real question is:
| * How can we make OE easier to use? *
| Most of the doubts and questions here will just go away once you
| really understand it. That's the hardest part, definitely much harder
| then discussing on the mailing list. I think that's the real problem.
Yeah. We have enough terrifying problems fighting against us already.
Today there is a BIG barrier to entry to contribute.
| We still don't have a nice develop environment. The way I see it
| there are 2 ways:
| 1. we teach people how to develop with OE.
We already established this is a big task. Really, we are here to make
cool phones. I didn't see anything to make me believe that OE adds more
than ONE thing towards that goal: working cross build. Why should
Openmoko become an OE University, it does nothing for us except try to
make up for the massive block OE is making for casual contribution.
| 2. we use another tool for development, like poky sdk.
I didn't understand what this does for me yet, but I am encouraged by
the step-by-step Marcin posted that it seems some auto dependency -dev
grabber or something that mortals might be able to operate.
| 3. (toolchain is not an option because most of the time it's best
| suited to kernel/boot developers)
| I don't know which one is better and I haven't got the time to try it.
| But *none* of them is related to a good build system.
4. We suddenly realize we're just making packages for a "PC", and we
should use a normal distro with some solution for cross, and not learn
and force everyone else to learn a big bunch of special case stuff.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the distro-devel