Openmoko build infrastructure questions

Richard Purdie rpurdie at rpsys.net
Thu Apr 17 00:32:39 CEST 2008


On Wed, 2008-04-16 at 19:04 -0300, Werner Almesberger wrote:
> > OE as a development tool:
> 
> This is where I see the big problem area. Why should I need substantially
> more than  make CC=arm-angstrom-linux-gnueabi-gcc  ? I don't expect this
> to figure out dependencies for me. I know that make doesn't do such
> things, but there's probably a README that will warn me about unusual
> stuff.
> 
> I don't want it to build a cross-compiler for me. And I certainly don't
> want it to install a secondary system environment for me in which I'm
> supposed to live while trying to compile and perhaps change that package.

The problem is everyone has a different expectation of a development
environment. Some want an IDE, some want their own editor, some just
want a shell prompt. The trick is finding something that can please the
most people.

> If the magic phrase is configure --target=mumble --prefix=blah, so be it.
> Perhaps a little README.Openmoko or README.OE could guide me. That could
> come with the original package or Openmoko/OE could provide it. The
> height of luxury would be a shell script that contains the few lines of
> wisdom I really need to care about here.

I'd love to see the meta-toolchain environment script expanded to add a
shell function which has the right configure options in it!

> I'll expect any package that's really worth keeping will eventually find
> its way into the distribution, so all these issues will be solved for me
> in the future when I wish meet the same package as a mere user, not as a
> developer. If it ends up a permanent local addition with no support from
> upstream, then I'll most likely abandon it as well, since it's just not
> worth the effort.

This is the switchover between the developer and the distro. With OE,
adding a .bb file is trivial and if the software is any use, there is no
harm in merging it.

> So this last role, that of the development tool, is where I see OE fail
> us. All I need is the small task of running the right build command,
> and maybe set up a few files and fix a few portability issues in the
> sources. Instead, I get asked to spend at least a day and significant
> system resources to set up and build a monster machine that will let me
> become my own distribution czar, and - almost as an afterthought - will
> also let me build that package.

OE is not a development tool. Yet.

Some OE devs, particularly me do want to see it become one and know all
the potential is there. This is where I mention packaged staging and
other such innovations. I agree this is still a step beyond what an
application developer needs though, meta-toolchain is the best offering
for them.

> That's why I love John's toolchain. It does exactly what I need to
> successfully build things with "make", and I can download and set it
> up in a few minutes, using blatantly obvious operations. It doesn't
> force me to join a new religion, it doesn't force me to learn some IDE
> and adapt my workflow to its logic, it doesn't waste my time by
> building its own microcosmos where it can be god. It just makes sure
> that the same sane build process I know works for native builds
> continues to work sanely also for cross-compilation.
> 
> Now, there are obviously limitations to this approach. E.g., if
> something really doesn't want to be cross-compiled, I'll hit a problem.
> Also, if it needs libraries John didn't think I'd need, there's another
> problem.

It is just a case of "opkg-target install foo-dev.ipk" with some tweaks
from poky which Graeme could probably merge in about 10 minutes.

> Packages that are just plainly hostile to cross-compilation need
> patching. So if I have to touch their source, I'd need some way to
> find those patches. Ideally, they would have been merged upstream long
> ago, but I understand that this sometimes may not have happened yet,
> or that some developers are just unresponsive. That's the first problem
> to solve.

With Poky we've simply said we'll only deal with autotool'd packages
since they're at least predictable even if you dislike autotools. The
IDE can generate dummy boilerplate so its not that bad from an app
developer perspective.

> >From this discussion, I gather that Poky is basically the natural
> extension of the toolchain approach that solves the second problem,
> namely the libraries something may depend on. Is this so ? If yes, can
> we make OE and Poky work together, so that each is used where it is
> strong, and lets the other take over where it isn't ? Or if they can't
> work together, can OE at least steal the good ideas ?

"John's toolchain" is I think built from meta-toolchain.bb. Almost all
the developments in the past year in meta-toolchain have come from Poky,
most of them from me. Poky is just an OE distro at the end of the day so
you should be able to use all its bits with minimal effort.

For reference I wrote meta-toolchain in a effort to show that OE can
ease the development environment side of things and your comments above
show it really does work :).

Cheers,

Richard




More information about the distro-devel mailing list