Unable to use OM build system

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> What kind of breakage can we expect with that imagined change?
|
| Local shared libraries not being what the cross-toolchain was built
| for comes to mind. Luckily, gcc and friends don't need a lot:

Well we are providing a magic toolchain tarball that works OK here, so I
didn't expect trouble in this direction, as you say the dependencies are
very light.  It's more -->

| Another issue would be exotic build tools that change frequently
| and in incompatible ways.

Yes I can imagine stuff needing particular builds of autotools or
whatever.  But two reasons make me figure that this is not a killer:

~ - we mainly talk about cross-building packages available for all common
distros natively.  Ergo, these packages can be compiled with the tools
in the distro.  That particular revision or what extra workarounds I
dunno.  But, it's clearly true.

~ - in this model we do not randomly recompile everything.  Devs are
normally working on an app that links against these kind of packages, or
a new lib.  If you work on DM2 and it need gtk or whatever, almost
certainly no way does it mean you will start messing with gtk source.
So it means you NEVER needed to compile gtk or whatever: therefore any
quirks that may or may not blow up its build on your host system are
totally moot and you can go ahead and use it with confidence -- you just
use the packages for it.  You'll never care it doesn't build without
autotools-1.2beta because you'll never build it.

Put another way, the GentoOE methodology forces every user into a build
worst-case that 99.99% of users (except the ones that plan source edits
in every single library used by their app) will never ever need.  By
fixing that the entire build action will suddenly become way less
sensitive to the host OS even without the bitbake-forced host-built tools.

And it means folks who like bitbake doing its thing how it does can
stick with it, and nobly take the hit to build packages that everyone
else can use without having to use bitbake.

| Any subtle quirks in other tools required during the build are
| probably upstream problems. Likewise, if a common tool we need for
| building that has a well-known incompatibility that for some
| reason can't get fixed just by upgrading probably deserved a change
| in the build process.
|
| I like the binary-toolchain plus precompiled-cross-package installer
| approach. That takes the pain away from the average developer while
| still giving our distribution makers the flexibility and control they
| need.

Great.

| And for those items one really can't avoid building locally, a look
| in the .bb file can probably provide valuable hints about any surprises
| one may encounter.

Agreed.  But a "build system" that worked like rpmbuild which eats a
spec file and spits out as many packages as specified (one or more
binary, -dev, source, etc) would be most perfect, eating the distro .bb
and creating known-same-config-option packages.  Making your own script
to build unpackaged binaries is really a sad workaround for this not
being offered already -- not that one should sniff at a sad workaround
in a pinch.

- -Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgLjC8ACgkQOjLpvpq7dMr2/gCdHOUYpRBB/7r5dYJQzvUK4Z1l
nJ8An1QF+EwRqHsp8tYQ3jmi/5ZplaPi
=iUZK
-----END PGP SIGNATURE-----