[maemo-developers] Public maemo repository

[From: Rodrigo Vivi]

Hi Marius,

I'll call by "end user" those developers that use the distro/SDK to
develop their programs and by "developer" those that are coding the
distro/SDK itself.

OE makes developer's life easier because under OE repository there are
a lot of package descriptions and tasks definitions that bitbake (that
is a task executor) uses to build what you tell to build. Bitbake is
too flexible.

But for the end user that is compiling and recompiling his code it is
not a good idea to use the OE and bitbake to do the cross-compilation.
At that point scratchbox can be useful.

OE makes the end user's life easier just when his program is ready to
be packed. Instead of create a debian control dir, with a lot of
complex files and rules, you just need to add a .bb file with few
lines of description and use the bitbake to cross-compile, test and
pack it.

Yes, it is too close to Gentoo. It is easier to pack. And about the
machines it depends on a machine configuration file that you define in
OE. If you want a generic arm compilation you can do it, but don't
forget that n770 and n800 has some important differences: n770 is
armv5te with soft fpu and n800 is armv6 with hard fpu.

I'm not telling that dpkg-buildpackage approach is bad and I know that
emdebian team is doing a good work to adapt it to cross compiling.
What I want to avoid is the creation of debian controls files that I
believe that is to painful. Some Months ago Koen said me a truth:
"Hackers like to code and don't want to spend their time packing"

Regards,
Vivi.

On 7/27/07, Marius Vollmer <marius.vollmer at nokia.com> wrote:
> "ext Rodrigo Vivi" <rodrigo.vivi at gmail.com> writes:
>
> > Another thing that is necessary to say is that OpenEmbedded and
> > scratchbox can coexist. OE is a great buildsystem to build the
> > distribution itself (avoiding monkey work) and scratchbox is a great
> > cross-compile environment that is very useful to make faster the
> > compilation in a SDK like maemo.
>
> Let me show my ignorance by digging into this a bit deeper.
>
> My understanding is that OpenEmbedded is a concrete set of software
> components that come with detailed instructions for BitBake to
> cross-compile them for a number of host architectures[1].
>
> Thus, the BitBake recipes for OpenEmbedded components make sure that
> these components can be cleanly cross-compiled.
>
> Scratchbox, on the other hand, 'fakes' a complete emulated environment
> for the host architecture and the usual autotooled software components
> can be compiled natively in that environment.
>
> Thus, Scratchbox saves you the need to make your software cleanly
> cross-compilable.[2]
>
> These two approches don't conflict, of course.  But what is the point
> of using Scratchbox if all your components are also contained in
> OpenEmbedded?  In other words, if your software is cross-compilable,
> why use Scratchbox?
>
> [ There might be components that are not cross-compilable, such as 3rd
>   party applications that are not part of OpenEmbedded.  We shouldn't
>   tolerate these kinds of components, I'd say, since their existence
>   will just increase the chaos.
> ]
>
> And, if your software is cross-compilable, why use BitBake?  Isn't
> dpkg-buildpackage good enough for us?  The Emdebian project is going
> that direction, I think, and it's a good direction.[3]
>
> I would expect BitBake to support more host configurations in an
> easier way than dpkg-buildpackage (for example, changing a compiler
> flag and recompiling the whole thing), but we don't want to go there,
> I'd say.  There should be one architecture (in the Debian sense) that
> runs on as much hardware platforms as possible.
>
> I don't want to compile separately for the 770 and the N800, or for
> McCaslin and Menlow, the same way I don't compile separately for Intel
> and AMD.  In that sense, OpenEmbedded is too close to Gentoo for my
> taste. :)
>
>
> [1] I think cross-compiling terminology goes like this, at least in
>     the GNU project:
>
>     `--build=BUILD-TYPE'
>          the type of system on which the package is being configured and
>          compiled.  It defaults to the result of running `config.guess'.
>
>     `--host=HOST-TYPE'
>          the type of system on which the package will run.  By default it
>          is the same as the build machine.  Specifying it enables the
>          cross-compilation mode.
>
>     `--target=TARGET-TYPE'
>          the type of system for which any compiler tools in the package will
>          produce code (rarely needed).  By default, it is the same as host.
>
> [2] I think it's close to a miracle that this actually works well
>     enough in practice.
>
> [3] If anything, they are too careful by forking all the packaging
>     (emdebian/ versus debian/).  Debian prides itself for supporting
>     dozens of architectures, surely making cross-compile-cleanliness
>     an important target will not be rejected?
>


-- 
Rodrigo Vivi
INdT - Instituto Nokia de Tecnologia
Blog: http://blog.vivi.eng.br
GPG: 0x905BE242 @ wwwkeys.pgp.net