Getting Started -Makefile

Getting Started -Makefile

[David Farning]

I think that my getting started Makefile is ready for testing.

To setup a development BitBake\OpenEmbedded system:

##Do not run this from an existing bb/oe directory.  It will##
##overwrite parts of your local.conf.                       ##

make a new  test directory
change to the test directory
copy Makefile to directory

$make setup
$make build-package-vim

This eliminates many of problems the new users have setting up bb
and oe.  There is no need to know any thing about svn of monotone.

I am caching sources in HOME to reduce traffic while testing.
I am still working on the quem testing image setup so I did not 
include it.

Thanks
David Farning









# "Makefile" - a Makefile for setting up OpenEmbedded builds
#
# Copyright (c) 2007  David Farning <dfarning@gmail.com>
# All rights reserved.
# 
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# version 2 as published by the Free Software Foundation.

# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor,
# Boston, MA  02110-1301, USA
#
# Thanks to Rod Whitby for the OpenMokoMakefile

# Set BITBAKE_SVN_REV to either HEAD or 1.8
BITBAKE_SVN_REV = HEAD

ifeq ("${BITBAKE_SVN_REV}","HEAD")
BB_SVN_PATH := bitbake/trunk/bitbake
else
BB_SVN_PATH := bitbake/branches/bitbake-1.8
endif

MTN := mtn
#Set OPENEMBEDDED_MTM_REV to either head of a specific revision
OPENEMBEDDED_MTN_REV = HEAD

ifneq ("${OPENEMBEDDED_MTN_REV}","HEAD")
OPENEMBEDDED_REV_FLAGS = -r ${OPENEMBEDDED_MTN_REV}
endif
OE_SNAPSHOT_SITE := http://www.openembedded.org/snapshots


MACHINE := qemux86
DISTRO := angstrom-2007.1

CWD := pwd

###############################################################################
# Setup
###############################################################################

.PHONY: setup
setup:  setup-bitbake setup-mtn setup-openembedded setup-config setup-env

.PHONY: setup-bitbake
setup-bitbake stamps/bitbake:
	[ -e stamps/bitbake ] || \
	( svn co -r ${BITBAKE_SVN_REV} svn://svn.berlios.de/${BB_SVN_PATH} bitbake )
	[ -d stamps ] || mkdir stamps
	touch stamps/bitbake

OE.mtn:
	if [ -z "`${MTN} --version | awk '{ print $$2; }'`" ] ; then \
	  echo 'Cannot determine version for monotone using "${MTN} --version"' ; \
	  false ; \
	fi
	[ -e OE.mtn ] || \
	( ( version=`${MTN} --version | awk '{ print $$2; }'` ; \
	    wget -c -O OE.mtn.bz2 \
		${OE_SNAPSHOT_SITE}/OE-this-is-for-mtn-$$version.mtn.bz2 || \
	    wget -c -O OE.mtn.bz2 \
		${OE_SNAPSHOT_SITE}/OE.mtn.bz2 ) && \
	  bunzip2 -c OE.mtn.bz2 > OE.mtn.partial && \
	  mv OE.mtn.partial OE.mtn )

.PHONY: setup-mtn
setup-mtn stamps/OE.mtn:
	[ -e OE.mtn ] || \
	${MAKE} OE.mtn
	[ -e stamps/OE.mtn ] || \
	( ${MTN} --db=OE.mtn db migrate && \
	  ${MTN} --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev )
	[ -d stamps ] || mkdir stamps
	touch stamps/OE.mtn

.PHONY: setup-openembedded
setup-openembedded stamps/openembedded: stamps/OE.mtn
	[ -e stamps/openembedded ] || \
	( ${MTN} --db=OE.mtn checkout --branch=org.openembedded.dev \
		${OPENEMBEDDED_REV_FLAGS} openembedded ) || \
	( ${MTN} --db=OE.mtn checkout --branch=org.openembedded.dev \
		-r `${MTN} --db=OE.mtn automate heads org.openembedded.dev | head -n1` openembedded )
	[ -d stamps ] || mkdir stamps
	touch stamps/openembedded

.PHONY: setup-config
setup-config build/conf/local.conf:
	[ -e build/conf/local.conf ] || \
	(   mkdir -p build/conf; \
	    cp openembedded/conf/local.conf.sample build/conf/local.conf; \
	    sed -i -e 's/^#[[:space:]]*MACHINE[[:space:]]*=[[:space:]]*\".*\"/MACHINE = \"${MACHINE}\"/' build/conf/local.conf; \
	    sed -i -e 's/^#[[:space:]]*DISTRO[[:space:]]*=[[:space:]]*\".*\"/DISTRO = \"${DISTRO}\"/' build/conf/local.conf; \
	    sed -i -e 's|BBFILES := "$${@bb.*|BBFILES := "${shell pwd}/openembedded/packages/*/*.bb"|' build/conf/local.conf; \
	    sed -i -e 's|# EDIT THIS FILE.*||' build/conf/local.conf; \
	    sed -i -e 's|REMOVE_THIS_LINE.*||' build/conf/local.conf; )

setup-env:
	[ -e setup-env ] || \
	echo 'export OEDIR="'`pwd`'"'                            > setup-env

	echo \
	'export BBPATH="$${OEDIR}/build:$${OEDIR}/openembedded"' >> setup-env

	echo \
	'export PATH="$${OEDIR}/bitbake/bin:$${PATH}"'            >> setup-env
###############################################################################
# Update
###############################################################################

.PHONY: update
update: update-bitbake update-mtn update-openembedded 

.PHONY: update-bitbake
update-bitbake: stamps/bitbake
	cd bitbake && svn update -r ${BITBAKE_SVN_REV}

.PHONY: update-mtn
update-mtn: stamps/OE.mtn
	if [ "${OPENMOKO_MTN_REV}" != "`(cd openembedded && ${MTN} automate get_base_revision_id)`" ] ; then \
		${MTN} --db=OE.mtn pull monotone.openembedded.org org.openembedded.dev ; \
	fi

.PHONY: update-openembedded
update-openembedded: update-mtn stamps/openembedded
	( cd openembedded && ${MTN} update ${MTN_REV_FLAGS} ) || \
	( cd openembedded && ${MTN} update \
		-r `${MTN} automate heads | head -n1` )

###############################################################################
# Build Tests
###############################################################################

#FIXME build sdk should sdk be what I have been calling the cross compiler + tools?
#FIXME build test package
#FIXME build test distro
#FIXME build test qemu image

###############################################################################
# Build Package
###############################################################################

.PHONY: build-package-%
build-package-%: setup
	( . ./setup-env \
		&& echo $$PATH \
		&& echo $$BBPATH \
		&& bitbake -c build $* )

.PHONY: rebuild-package-%
rebuild-package-%: setup
	( . ./setup-env && bitbake -c rebuild $* )

.PHONY: clean-package-%
clean-package-%: setup
	( . ./setup-env && bitbake -c clean $* )

###############################################################################
# Clean
###############################################################################

.PHONY: clean
clean: clean-openembedded

.PHONY: clean-openembedded
clean-openembedded:
	rm -rf tmp

###############################################################################
#  Clobber
###############################################################################

.PHONY: clobber
clobber: clobber-bitbake clobber-openembedded clobber-config clobber-env

.PHONY: clobber-bitbake
clobber-bitbake:
	rm -rf bitbake stamps/bitbake

.PHONY: clobber-openembedded
clobber-openembedded: clean-openembedded
	rm -rf openembedded stamps/openembedded

.PHONY: clobber-config
clobber-config:
	rm -rf build/conf/local.conf

.PHONY: clobber-env
clobber-env:
	rm -rf setup-env

Re: Getting Started -Makefile

[Koen Kooi]

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

David Farning schreef:
> I think that my getting started Makefile is ready for testing.
> 
> To setup a development BitBake\OpenEmbedded system:
> 
> ##Do not run this from an existing bb/oe directory.  It will##
> ##overwrite parts of your local.conf.                       ##
> 
> make a new  test directory
> change to the test directory
> copy Makefile to directory
> 
> $make setup

nice

> $make build-package-vim

$deity just killed a few hundred kittens.

At OEDEM we decided that we won't tolerate kindergarten-like,
hand-holding wrappers around bitbake. Typing 'bitbake vim' isn't rocket
science. To paraphrase Mickey: "If typing 'bitbake <foo>' is too hard,
you shouldn't be using OE".

At OEDEM we also discovered that people we clueless about various
pitfalls documented in local.conf.sample, so I'm also unsure if we
should make it recommended practice to generate a working local.conf.
The killswitch is in local.conf.sample for a good reason; it forces
people to read it.

> This eliminates many of problems the new users have setting up bb
> and oe. 

And the makefile should stop after setting it up.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHQZ6fMkyGM64RGpERArNJAJ0RdpWrjbhYIbX/1nQZ3U6bgto4MwCfZhg/
EMR7B5VUHKTygSQMURGdAjU=
=72r1
-----END PGP SIGNATURE-----

Re: Getting Started -Makefile

[Rod Whitby]

Koen Kooi wrote:
> David Farning schreef:
>> $make setup
> 
> nice
> 
>> $make build-package-vim
> 
> $deity just killed a few hundred kittens.
> 
> At OEDEM we decided that we won't tolerate kindergarten-like,
> hand-holding wrappers around bitbake. Typing 'bitbake vim' isn't rocket
> science. To paraphrase Mickey: "If typing 'bitbake <foo>' is too hard,
> you shouldn't be using OE".

The challenge I put to yourself and a couple of other people from the OM
core team in IRC a couple of weeks or months ago still stands:

Show how you can use bitbake such that you can cd into a build area, and
type a *single* bitbake command to do a build, then cd into a different
build area (with a different distro and machine) and type a *single*
bitbake command to do a build there.  No other commands are allowed.

At the moment, you need to set many environment variables before bitbake
can do it's job, and you need to reset them when you move into a
different area to do a different build.  That's the reason why there are
makefile wrappers around simple bitbake commands.

If we can fix the underlying problem (needing to type more than one
command to build an image with bitbake), then I will fully support a
move to get rid of all bitbake wrappers from all the Makefiles that I
manage.

Instead of just saying that you won't tolerate something, how about
understanding *why* that something is done, and then work together to
improve the existing tools so that something no longer needs to be done
cause the tools already cover that use case.

-- Rod

Re: Getting Started -Makefile

[pHilipp Zabel]

On Nov 20, 2007 12:51 AM, Rod Whitby <rod@whitby.id.au> wrote:
> Koen Kooi wrote:
> > David Farning schreef:
> >> $make setup
> >
> > nice
> >
> >> $make build-package-vim
> >
> > $deity just killed a few hundred kittens.
> >
> > At OEDEM we decided that we won't tolerate kindergarten-like,
> > hand-holding wrappers around bitbake. Typing 'bitbake vim' isn't rocket
> > science. To paraphrase Mickey: "If typing 'bitbake <foo>' is too hard,
> > you shouldn't be using OE".
>
> The challenge I put to yourself and a couple of other people from the OM
> core team in IRC a couple of weeks or months ago still stands:
>
> Show how you can use bitbake such that you can cd into a build area, and
> type a *single* bitbake command to do a build, then cd into a different
> build area (with a different distro and machine) and type a *single*
> bitbake command to do a build there.  No other commands are allowed.
>
> At the moment, you need to set many environment variables before bitbake
> can do it's job, and you need to reset them when you move into a
> different area to do a different build.  That's the reason why there are
> makefile wrappers around simple bitbake commands.

So why not provide a simple shell wrapper instead of setup-env and the
Makefile's build-package-% part? That way, at least people would learn
the correct bitbake syntax from the beginning.

$ cat ~/bin/bitbake
#!/bin/sh
export OEDIR=${OEDIR:-$PWD}
export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
/usr/local/bin/bitbake $*

> If we can fix the underlying problem (needing to type more than one
> command to build an image with bitbake), then I will fully support a
> move to get rid of all bitbake wrappers from all the Makefiles that I
> manage.

The question is how to fix this problem correctly.
One possibility would be that bitbake, if BBPATH is unset, issues a
warning and scans the file system (starting from the $PWD) for a
certain file (local.conf) in which BBPATH would be specified.

regards
Philipp

Re: Getting Started -Makefile

[Tim Bird]

pHilipp Zabel wrote:
> $ cat ~/bin/bitbake
> #!/bin/sh
> export OEDIR=${OEDIR:-$PWD}
> export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
> /usr/local/bin/bitbake $*

This is nice.  Can someone tell me why this isn't
the default behavior of bitbake now?  (I'm honestly
not trolling :-)   There must be some good reason
to allow bitbake to be used outside of a build
directory.  Make (which bitbake resembles
in some aspects), is sensitive to it's starting
directory.  Why not bitbake?
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Getting Started -Makefile

[Cliff Brake]

On Nov 20, 2007 12:57 PM, Tim Bird <tim.bird@am.sony.com> wrote:
> pHilipp Zabel wrote:
> > $ cat ~/bin/bitbake
> > #!/bin/sh
> > export OEDIR=${OEDIR:-$PWD}
> > export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
> > /usr/local/bin/bitbake $*
>
> This is nice.  Can someone tell me why this isn't
> the default behavior of bitbake now?  (I'm honestly
> not trolling :-)   There must be some good reason
> to allow bitbake to be used outside of a build
> directory.  Make (which bitbake resembles
> in some aspects), is sensitive to it's starting
> directory.  Why not bitbake?

One problem is bitbake is typically run from a svn co directory, so
you need to modify the path anyway.  Once you are stuck with
source'ing a script, it is not a lot more work to add BBPATH.

It might be a good idea to have defaults.  I'm sure with a few lines
of Python, the above script could be implemented directly in bitbake,
so why not -- if the variables are not defined, then use the defaults.
 But often something a little different is required.

For, example, most of my builds use the following setup:

export OEDIR="/build/svs_oe_update/oe2"
export TOPDIR="${OEDIR}/build/angstrom-2007.1"
export BBPATH="${OEDIR}/oe/custom:${TOPDIR}:${OEDIR}/oe/org.openembedded.dev"
export PATH="${OEDIR}/bitbake/bin:${PATH}"

The defaults might be useful for many people, but people who really
use OE often need something a little different.  My setup allows for
OE overlays, target multiple distributions (2007.1, or 2008.1, etc).
Also, defaults might get in the way of people who forget to source
their setup-env script and lead to confusing error messages, etc.  Too
much magic can be confusing too ...

I mostly use OE to help customers build vertical embedded systems.  I
use Makefiles, but as mentioned by others, it is mainly just for setup
so that I can quickly switch machines, changes distributions, glibc vs
uclibc, etc.  After that, I run bitbake.  I think of a Makefile as
documentation so when I come back to a project in 1 year, I don't have
to remember how to set up a build and what targets need to be built.
My customers seem to like a Makefile.  They rarely get into the doing
OE development, but being able to run a complete build gives them some
level of comfort if I would get hit by a truck, they would at least
have the build system and could pick up where I left off.  So for my
usage, Makefiles (or shell scripts, or whatever you want to use) are
project specific, and typically need customized for what you are
doing.  As an example, as much as I like Rod's Makefile wizardry, I
prefer to do a few things differently and ending up writing my own
version.  So there is probably no one Makefile or setup script or way
of doing things that is going to work for most people -- which is fine
IMO.

Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com

Re: Getting Started -Makefile

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

Make reads it's behavior from a Makefile.

Bitbake contains specific behaviors and reads some configuration from disk.

I don't think they are very similar. I kind of like not caring where I 
run bitbake from and being able to switch build trees by changing the 
environment.

Although I do see some merits to Tim's question, especially if it solves 
real-world problems.  (I mean really solve, not just mask)

Philip

Tim Bird wrote:
> pHilipp Zabel wrote:
>> $ cat ~/bin/bitbake
>> #!/bin/sh
>> export OEDIR=${OEDIR:-$PWD}
>> export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
>> /usr/local/bin/bitbake $*
> 
> This is nice.  Can someone tell me why this isn't
> the default behavior of bitbake now?  (I'm honestly
> not trolling :-)   There must be some good reason
> to allow bitbake to be used outside of a build
> directory.  Make (which bitbake resembles
> in some aspects), is sensitive to it's starting
> directory.  Why not bitbake?
>  -- Tim
> 
> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Getting Started -Makefile

[Florian Boor]

Hi,

Tim Bird schrieb:
> This is nice.  Can someone tell me why this isn't
> the default behavior of bitbake now?  (I'm honestly
> not trolling :-)   There must be some good reason
> to allow bitbake to be used outside of a build
> directory.  Make (which bitbake resembles
> in some aspects), is sensitive to it's starting
> directory.  Why not bitbake?

that's a pretty good point. In my opinion the fact that you need to set
environment variables in addition to your configuration files is a pain anyway.
I would expect bitbake to search for all configuration information in
$PWD/conf/*.conf and that's it. That would reduce the initial overhead and makes
it _much_ easier for new users to get along with OE.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Florian,

Wednesday, November 21, 2007, 1:25:34 AM, you wrote:

> Hi,

> Tim Bird schrieb:
>> This is nice.  Can someone tell me why this isn't
>> the default behavior of bitbake now?  (I'm honestly
>> not trolling :-)   There must be some good reason
>> to allow bitbake to be used outside of a build
>> directory.

>> Make (which bitbake resembles
>> in some aspects), is sensitive to it's starting
>> directory.  Why not bitbake?

> that's a pretty good point. In my opinion the fact that you need to set
> environment variables in addition to your configuration files is a pain anyway.
> I would expect bitbake to search for all configuration information in
> $PWD/conf/*.conf and that's it.

  Your expectations are wrong, as instead bitbake searches only for a
single file called "conf/bitbake.conf" under list of paths specified by
envvar BBPATH. Anything else happens as directed by that file, and
that's application-level configuration, not bitbake's per se.

  And there're good reasons it does that, which become obvious when
you start to think about it. After all, bitbake.conf is *master*
config, so how are you supposed to get that in *your* $PWD? We don't
talk manual copying here, no? Because it's one thing is to set one
well-defined envvar, and quite another is to shuffle pristine files
around just to get stuff started - the latter is rather non-scalable.

  Also, do you really think such complex system as OpenEmbedded would
allow user to source master config from his location instead of the
system's own? Nope, that would amount to letting user to shoot himself
not even in leg, but straight into head.
  
> That would reduce the initial overhead and makes
> it _much_ easier for new users to get along with OE.

#1

>> TMPDIR = "/OE/tmp/${DISTRO}"
>> No need for seperate build areas.
>> [And] If you use angstrom you can even
>> switch C library ([e]glibc vs uclibc), as outlined in
>> http://www.angstrom-distribution.org/building-angstrom
>> You can even have per distro tweaks using include statements, but I'll
>> leave that as an exercise to the reader. No need for seperate build
>> areas. At all.
> 
> as soon as you are working with multiple builds in parallel or you want to
> specify versions you need multiple build directories.

#2

  So, again conflicting expectations: on the one hand, you call for it
to be easy for users, and on the other hand, you argue with core OE
maintainer, who suggests a clean approach for system setup - you
ignore that, and instead tell that you're going to do it the way you
get used to, thanks to bitbake's flexibility.

  So, what people really want - be forced to adhere to best practices
or left with the easy choice of subverting them for their own
convenience?

  IMHO, where OpenEmbedded should head to is to promoting local.conf
to "advanced" features, left for the people who are able to setup
environment variables. Mere users should be forced to use repository
configs, with the only parameters to vary are DISTRO and MACHINE.

  And yep, those params are still to be passed via environment,
because it's easier to just run:

DISTRO=angstrom MACHINE=collie bitbake x11-image

than:
1. Edit some file somewhere
2. run bitbake

  (But for people who're really not familiar with Unix process environment,
bitbake switches --distro and --machine can be added).


> Greetings

> Florian




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Rod Whitby]

Florian Boor wrote:
> Tim Bird schrieb:
>> This is nice.  Can someone tell me why this isn't
>> the default behavior of bitbake now?  (I'm honestly
>> not trolling :-)   There must be some good reason
>> to allow bitbake to be used outside of a build
>> directory.  Make (which bitbake resembles
>> in some aspects), is sensitive to it's starting
>> directory.  Why not bitbake?
> 
> that's a pretty good point. In my opinion the fact that you need to set
> environment variables in addition to your configuration files is a pain anyway.
> I would expect bitbake to search for all configuration information in
> $PWD/conf/*.conf and that's it. That would reduce the initial overhead and makes
> it _much_ easier for new users to get along with OE.

If that was enacted, then the need for any Makefile support for building
individual packages would be removed (literally - I would remove those
targets from the Makefiles I maintain).

-- Rod

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Tim,

Tuesday, November 20, 2007, 7:57:51 PM, you wrote:

> pHilipp Zabel wrote:
>> $ cat ~/bin/bitbake
>> #!/bin/sh
>> export OEDIR=${OEDIR:-$PWD}
>> export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
>> /usr/local/bin/bitbake $*

> This is nice.  Can someone tell me why this isn't
> the default behavior of bitbake now?  (I'm honestly
> not trolling :-)   There must be some good reason
> to allow bitbake to be used outside of a build
> directory.  Make (which bitbake resembles
> in some aspects), is sensitive to it's starting
> directory.  Why not bitbake?

   This is attempt to put it backwards. It's not to allow bitbake
to be used outside of build directory, it's to allow *source* be
outside build directory. Real hardcore make users might have heard
about VPATH envvar and out-of-source building.

   Why not default? Well, because what make builds is usually ones to
tens of megabytes, while bitbake builds tens to hundreds gigabytes.
Those who're brave to undertake such endeavour, are expected to get
some understanding of what they're going to be thru by learning and
doing some setup with their own hands. I'm sure that was original
motivation why bitbake and OE was setup that way. Of course, that was
quite some time ago, when disks were much smaller. Let's see if this
will change now.


>  -- Tim


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Rod Whitby]

Paul Sokolovsky wrote:
>    Why not default? Well, because what make builds is usually ones to
> tens of megabytes, while bitbake builds tens to hundreds gigabytes.
> Those who're brave to undertake such endeavour, are expected to get
> some understanding of what they're going to be thru by learning and
> doing some setup with their own hands.

And therein lies the rub.  The reason why the Makefiles came about is
because there is a large number of distribution users who are forced to
use OE (cause it is the only way to develop applications for or build
custom images for a certain platform), but they have *no* interest in
understanding how to build tens to hundreds of gigabytes of stuff with
bitbake.  They are application developers and image customisers, not
distribution developers.

And yes, we all agree with BitBake/OE was not designed for the "casual
user" who has been forced to use it cause there is no other way (for
example) to build an OpenMoko image or create a new application for
OpenMoko.  But the reality of today is that there is a large number of
such users, and they seem to prefer the convenience of the Makefiles.

-- Rod

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Rod,

Wednesday, November 21, 2007, 7:44:24 AM, you wrote:

> Paul Sokolovsky wrote:
>>    Why not default? Well, because what make builds is usually ones to
>> tens of megabytes, while bitbake builds tens to hundreds gigabytes.
>> Those who're brave to undertake such endeavour, are expected to get
>> some understanding of what they're going to be thru by learning and
>> doing some setup with their own hands.

[]

> And yes, we all agree with BitBake/OE was not designed for the "casual
> user" who has been forced to use it cause there is no other way (for
> example) to build an OpenMoko image or create a new application for
> OpenMoko.  But the reality of today is that there is a large number of
> such users, and they seem to prefer the convenience of the Makefiles.

  Nice! OpenMoko uses its Makefile on to of bitbake, Slug uses own
Makefile, Koen guy uses his autobuilder which he doesn't even bother
to publish, I use busyb on top of OE (http://linux-h4000.sourceforge.net/busyb/oe/).

   But what's the OE's and bitbake's problem with this? Because that's
how all Unix tools are used. What is the problem which needs to be
solved? If the problem formulates as "OE and bitbake sucks, because
I use Makefile on top of them", then it can as well stay that way -
everyone does use.

    If instead its "its hard for casual user to setup
a distro building environment", then we should be prepared to decide
what part of power and flexibility we're going to hide, if not remove,
from the users. I'd personally be glad to see extension of the user
base of OE, but if it would come at the expense of reduction of
*poweruser* base, that would be a bit said, so worth a bit of
planning.

> -- Rod



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Michael 'Mickey' Lauer]

Rod Whitby wrote:
> Paul Sokolovsky wrote:
>>    Why not default? Well, because what make builds is usually ones to
>> tens of megabytes, while bitbake builds tens to hundreds gigabytes.
>> Those who're brave to undertake such endeavour, are expected to get
>> some understanding of what they're going to be thru by learning and
>> doing some setup with their own hands.

> And therein lies the rub.  The reason why the Makefiles came about is
> because there is a large number of distribution users who are forced to
> use OE (cause it is the only way to develop applications for or build
> custom images for a certain platform), but they have *no* interest in
> understanding how to build tens to hundreds of gigabytes of stuff with
> bitbake.  They are application developers and image customisers, not
> distribution developers.

Guilty as charged. Lets try not to force these people to use OE -- we
can do this by releasing prebuilt toolchains. I'm going to start with
releasing an OpenMoko toolchain next week.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: Getting Started -Makefile

[Lorn Potter]

Michael 'Mickey' Lauer wrote:

> Guilty as charged. Lets try not to force these people to use OE -- we
> can do this by releasing prebuilt toolchains. I'm going to start with
> releasing an OpenMoko toolchain next week.


FYI, We have had a toolchain released when we first released Qtopia for 
Neo tech preview, built with CROSS_DIR = "/opt/toolchains/arm920t-eabi". 
I put it there because that is where the greenphone toolchain lived.

It would be nice if we were to use the same location for toolchains. So 
perhaps you could use our location? :)

Re: Getting Started -Makefile

[Esben Haabendal]

On Thu, 2007-11-22 at 14:20 +1000, Lorn Potter wrote:
> Michael 'Mickey' Lauer wrote:
> 
> > Guilty as charged. Lets try not to force these people to use OE -- we
> > can do this by releasing prebuilt toolchains. I'm going to start with
> > releasing an OpenMoko toolchain next week.
> 
> 
> FYI, We have had a toolchain released when we first released Qtopia for 
> Neo tech preview, built with CROSS_DIR = "/opt/toolchains/arm920t-eabi". 
> I put it there because that is where the greenphone toolchain lived.
> 
> It would be nice if we were to use the same location for toolchains. So 
> perhaps you could use our location? :)

And prevent people from installing both toolchains on the same machine
without fiddling with paths?

/Esbn

-- 
Esben Haabendal
Embedded Software Consultant, Dore Development ApS
Phone: +45 5192 5393  Email: eha@doredevelopment.dk

Re: Getting Started -Makefile

[Lorn Potter]

On Thursday 22 November 2007 18:14, Esben Haabendal wrote:
> On Thu, 2007-11-22 at 14:20 +1000, Lorn Potter wrote:
> > Michael 'Mickey' Lauer wrote:
> > > Guilty as charged. Lets try not to force these people to use OE -- we
> > > can do this by releasing prebuilt toolchains. I'm going to start with
> > > releasing an OpenMoko toolchain next week.
> >
> > FYI, We have had a toolchain released when we first released Qtopia for
> > Neo tech preview, built with CROSS_DIR = "/opt/toolchains/arm920t-eabi".
> > I put it there because that is where the greenphone toolchain lived.
> >
> > It would be nice if we were to use the same location for toolchains. So
> > perhaps you could use our location? :)
>
> And prevent people from installing both toolchains on the same machine
> without fiddling with paths?
>

The toolchain is more or less the same for openmoko and qtopia, and are 
compatible in the least. If you have the openmoko toolchain installed, you 
can compile Qtopia with that as well.




-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech

Re: Getting Started -Makefile

[Tim Bird]

Paul Sokolovsky wrote:
>    This is attempt to put it backwards. It's not to allow bitbake
> to be used outside of build directory, it's to allow *source* be
> outside build directory. Real hardcore make users might have heard
> about VPATH envvar and out-of-source building.

I use makefiles to build source code, or affect operations
in different locations in the file system, all the time.
It is convenient and familiar to have PWD be part of the
trigger for what operation I'm performing.  I realize
this is an artifact of years of using make.  But since
it's something I and most others have already learned,
it seems like it would be nice to leverage that experience.

> 
>    Why not default? Well, because what make builds is usually ones to
> tens of megabytes, while bitbake builds tens to hundreds gigabytes.

I don't see how this is relevant.  Maybe we are considering different
use cases.

> Those who're brave to undertake such endeavour, are expected to get
> some understanding of what they're going to be thru by learning and
> doing some setup with their own hands.
I have no idea why this should be so.

A few people have mentioned this similar theme - "if OE
hides the details, users won't be forced to learn what's
going on."  In the most general terms, computers EXIST
to allow people to not learn what's going on in complete detail.
So does OE.  It's just the invocation sequence and minimum
learning curve that people seem hung up on.

I have sensed that OE seems squarely targeted
at distro developers rather than end users.  Maybe this is
the disconnect.  The use cases for OE for developers and
users will be quite different.

> I'm sure that was original
> motivation why bitbake and OE was setup that way. Of course, that was
> quite some time ago, when disks were much smaller. Let's see if this
> will change now.

Indeed.  Thanks for the response.
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Tim,

Wednesday, November 21, 2007, 7:58:09 PM, you wrote:

> Paul Sokolovsky wrote:
>>    This is attempt to put it backwards. It's not to allow bitbake
>> to be used outside of build directory, it's to allow *source* be
>> outside build directory. Real hardcore make users might have heard
>> about VPATH envvar and out-of-source building.

> I use makefiles to build source code, or affect operations
> in different locations in the file system, all the time.
> It is convenient and familiar to have PWD be part of the
> trigger for what operation I'm performing.  I realize
> this is an artifact of years of using make.  But since
> it's something I and most others have already learned,
> it seems like it would be nice to leverage that experience.

  Just don't tell me about Makefiles - I love them too. ;-)

  And please don't take following personally, instead it's just
simile: there's big difference between 1) a user who install a distro
from CD, and then subverts its package management by installing
software from source with "./configure; make; make install" and 2) a
user who builds a distro which can be burned on a CD and then
installed for user #1.

>> 
>>    Why not default? Well, because what make builds is usually ones to
>> tens of megabytes, while bitbake builds tens to hundreds gigabytes.

> I don't see how this is relevant.  Maybe we are considering different
> use cases.

  It must be simple: if you have 2 partitions of 10Gb, you usually can
"make" anything in any place. But for OE, that means that you need a
bit more careful planning what to put where - may be you'll need to
split source vs build by different partitions for example. As OE
doesn't know what partition sized you have and where you mount them,
it just explicitly requires you to do path setup. That's it.

>> Those who're brave to undertake such endeavour, are expected to get
>> some understanding of what they're going to be thru by learning and
>> doing some setup with their own hands.
> I have no idea why this should be so.

> A few people have mentioned this similar theme - "if OE
> hides the details, users won't be forced to learn what's
> going on."

  If OE hides details, few users might be unpleasantly suprised,
for example, by the filled-in home. Moreover, if we hide arguably
important things, less people will learn it, and will be able to
progress/improve.

> In the most general terms, computers EXIST
> to allow people to not learn what's going on in complete detail.
> So does OE.  It's just the invocation sequence and minimum
> learning curve that people seem hung up on.

  We'd start a long philosophical discussion here, with one opinion of
dichotomy being the one above, and the other - if those people should
choose TV and popcorn instead ;-).

> I have sensed that OE seems squarely targeted
> at distro developers rather than end users.

  That's how I assumed it all the time.

>  Maybe this is
> the disconnect.  The use cases for OE for developers and
> users will be quite different.

  Yes, and it's good question what job is whose. For example, if
OE should adapt itself to end users, or if rather targetted
communities using OE should provide Makefiles, scripts, SDKs for
their end users.

  I'd personally regret if OE turned into another portage feel-alike
with warning signs like "You, mere mortal user, don't even dare to
change that setting!". So far, OE's way was more of "See that setting?
Learn what it does, and tweak it, if you're sure."


>> I'm sure that was original
>> motivation why bitbake and OE was setup that way. Of course, that was
>> quite some time ago, when disks were much smaller. Let's see if this
>> will change now.

> Indeed.  Thanks for the response.
>  -- Tim

> =============================
> Tim Bird
> Architecture Group Chair, CE Linux Forum
> Senior Staff Engineer, Sony Corporation of America
> =============================



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Rod Whitby]

Paul Sokolovsky wrote:
>   Yes, and it's good question what job is whose. For example, if
> OE should adapt itself to end users, or if rather targetted
> communities using OE should provide Makefiles, scripts, SDKs for
> their end users.

There are currently two targetted communities (nslu2-linux and openmoko)
who very publicly use Makefiles.  But yet, that is publicly scorned by
the OE core team (and Koen in particular) to the extent that it is a
minuted outcome of the last OE core team meeting.

So if the second option is not allowed by the OE core team, then perhaps
we should focus on the first option.  However, various individuals
continue to treat OE users (as opposed to OE developers) with scorn and
derision.

Does the OE core team simply not want people to use OE unless you are a
distribution developer?

-- Rod

Re: Getting Started -Makefile

[Tim Bird]

Rod Whitby wrote:
> Does the OE core team simply not want people to use OE unless you are a
> distribution developer?

This is an interesting option.  I have thought what I would do
if I were making an OE-based distribution available to
my own downstream customers (CELF test lab users, at the moment).
I would NOT request that they learn OE.  The learning curve
is too steep.

In a former life, I worked on a large and ornate build system for
Lineo.  We did a fairly interesting thing there (IMO), where
we had a mechanism to capture all the individual commands used to
build the distribution, and create a straight shell script. The
script allowed a customer to reproduce that exact build.  The sources were
pre-expanded, and the whole thing was put into an archive that
people could download.

If users wanted to customize the build, they could apply patches
or modify individual commands in the script.  To actually insert
these back into Lineo's build system, it required that they learn
how our system worked (or, more commonly, they just sent their
changes back to us).

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Rod,

Thursday, November 22, 2007, 1:17:31 AM, you wrote:

> Paul Sokolovsky wrote:
>>   Yes, and it's good question what job is whose. For example, if
>> OE should adapt itself to end users, or if rather targetted
>> communities using OE should provide Makefiles, scripts, SDKs for
>> their end users.

> There are currently two targetted communities (nslu2-linux and openmoko)
> who very publicly use Makefiles.  But yet, that is publicly scorned by
> the OE core team (and Koen in particular) to the extent that it is a
> minuted outcome of the last OE core team meeting.

  Well, this is really funny discussion. Everyone speaks about their
own itch, and is comes pretty clear, there're quite different itches
around. Now, we even have ethical plug here ;-).

> So if the second option is not allowed by the OE core team, then perhaps
> we should focus on the first option.  However, various individuals
> continue to treat OE users (as opposed to OE developers) with scorn and
> derision.

  Core team doesn't allow you to use Makefiles on top of OE?!! How can
that be? Your Makefile is on meta-level regarding OE, core team just
can't do anything against your using anything on top of it (without
employing real evil vigor). If Koen would tell you to not grep ps's
output, would you go patching ps instead? ;-D  So, let's separate
technical and organizational requirements from human ethics and
emotion here.

> Does the OE core team simply not want people to use OE unless you are a
> distribution developer?

  U-m-mmm, I love these conspiracy-talks! ;-D  So, do you want instead
to lock down users in some stone-age Makefiles, hiding The Truth and
hindering dissemination of The Knowledge? ;-))



  Rationale: I wonder if other people see it just like me: people have
various itches with OE, but at the same time *all* of them have
solutions for them! So, they just try to put their solutions upon
other folks, as the only right and all-encompassing. Well, maybe
instead to think that it's all pretty ok with OE, if it allows
different people to solve different needs, and it's not worth risking
to change it for the benefit of one fraction and ailment of others?

  Otherwise, if there's real good reason to move OE in *some*
direction, let's think how to do that. For example, making OE setup
for novice OE users easier is pretty valid point of course. But if
formulate it like, let's stop:

1. Talking about Makefiles. Because from pure logic it's clear that
it's harder to use *both* bitbake and Makefile than *only* bitbake.
And yes, we do talk about using *bitbake*, because we talk about *OE*
users, and OE uses bitbake, and not some make. If people want to talk
about making users not using bitbake, then IMHO, this grows
increasingly offtopic here, as this is OE list. Also, any OE
developer, not just coreteam, will frown on that, as OE developers
obviously want more, not less, people to use *OE* tools, and grow to
the level of improving and progressing them and OE.

2. Talking about multiple build areas and stuff like that. Obviously,
that's too advanced for novice to pull it in. And advanced users know
how to do that anyway. (It's just everyone thinks that his way is better
then peers' ;-) ).

3. Talking about random hacks. Acquainting users with a new system
starting with random hacks in it is not too good a way to present such
system.

> -- Rod



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Tim Bird wrote:
> I have sensed that OE seems squarely targeted
> at distro developers rather than end users.  Maybe this is
> the disconnect.  The use cases for OE for developers and
> users will be quite different.

This is a key observation. OE is targeted at people solving the problem 
of creating distro's for machines, not people developing software for 
these machines (we'll call these people "users").

I believe everyone agrees OE is not an ideal solution for users. What we 
do not agree on is the best way to support users.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Getting Started -Makefile

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Tim Bird wrote:
> I have sensed that OE seems squarely targeted
> at distro developers rather than end users.  Maybe this is
> the disconnect.  The use cases for OE for developers and
> users will be quite different.

This is a key observation. OE is targeted at people solving the problem 
of creating distro's for machines, not people developing software for 
these machines (we'll call these people "users").

I believe everyone agrees OE is not an ideal solution for users. What we 
do not agree on is the best way to support users.

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Getting Started -Makefile

[Rod Whitby]

pHilipp Zabel wrote:
> So why not provide a simple shell wrapper instead of setup-env and the
> Makefile's build-package-% part? That way, at least people would learn
> the correct bitbake syntax from the beginning.
> 
> $ cat ~/bin/bitbake
> #!/bin/sh
> export OEDIR=${OEDIR:-$PWD}
> export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
> /usr/local/bin/bitbake $*
>
>> If we can fix the underlying problem (needing to type more than one
>> command to build an image with bitbake), then I will fully support a
>> move to get rid of all bitbake wrappers from all the Makefiles that I
>> manage.
> 
> The question is how to fix this problem correctly.
> One possibility would be that bitbake, if BBPATH is unset, issues a
> warning and scans the file system (starting from the $PWD) for a
> certain file (local.conf) in which BBPATH would be specified.

Finally, someone who wants to help solve the problem, rather than just
dump on other development practices.  Thank you Philipp.

I personally feel that there should be a standard directory structure
mandated by OE (instead of just leaving it up to each developer to
choose how they want to set up OE this week), so that default behaviour
like the above can be added, and so that new users can be assisted
without needing to guess at what their directory structure and default
values are.

Part of the rationale for the Makefile setup is that you then have a
large group of developers who are all doing things *exactly* the same
way, with the same directory structure and same default contents of
configuration files.  That is a powerful way to assist new users and
make sure that problems in the build setup are found quickly, and that
solutions to those problems can be distributed just as quickly.

-- Rod

Re: Getting Started -Makefile

[Esben Haabendal]

On Tue, 2007-11-20 at 10:12 +0100, pHilipp Zabel wrote:
> On Nov 20, 2007 12:51 AM, Rod Whitby <rod@whitby.id.au> wrote:
> > Koen Kooi wrote:
> So why not provide a simple shell wrapper instead of setup-env and the
> Makefile's build-package-% part? That way, at least people would learn
> the correct bitbake syntax from the beginning.
> 
> $ cat ~/bin/bitbake
> #!/bin/sh
> export OEDIR=${OEDIR:-$PWD}
> export BBPATH=${BBPATH:-$OEDIR/build:$OEDIR/openembedded}
> /usr/local/bin/bitbake $*
> 
> > If we can fix the underlying problem (needing to type more than one
> > command to build an image with bitbake), then I will fully support a
> > move to get rid of all bitbake wrappers from all the Makefiles that I
> > manage.
> 
> The question is how to fix this problem correctly.
> One possibility would be that bitbake, if BBPATH is unset, issues a
> warning and scans the file system (starting from the $PWD) for a
> certain file (local.conf) in which BBPATH would be specified.

Something like that would be nice. When bitbake finds BBPATH unset, it
traverses from $PWD to / to find a .bbenv (or some other filename, but
local.conf is probably not a good one), which can setup BBPATH,
PYTHONPATH, OEDIR or whatever env virables is used in the
conf/local.conf file. To guard against bad bitbake versions (as BBPATH
is unset, bitbake can be expected to be picked up from a generic PATH)
it might be smart to introduce a variable in local.conf stating specific
or minimum version requirements for bitbake.

Would there by any problems in extending bitbake calling convention in
this way?

/Esben

-- 
Esben Haabendal
Embedded Software Consultant, Dore Development ApS
Phone: +45 5192 5393  Email: eha@doredevelopment.dk

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Esben,

Wednesday, November 21, 2007, 8:20:57 AM, you wrote:

[]

>> The question is how to fix this problem correctly.
>> One possibility would be that bitbake, if BBPATH is unset, issues a
>> warning and scans the file system (starting from the $PWD) for a
>> certain file (local.conf) in which BBPATH would be specified.

> Something like that would be nice. When bitbake finds BBPATH unset, it
> traverses from $PWD to / to find a .bbenv (or some other filename, but
> local.conf is probably not a good one), which can setup BBPATH,
> PYTHONPATH, OEDIR or whatever env virables is used in the
> conf/local.conf file.

  LOL. So, editing .bashrc is hard, while creating and editing some
obscure file is easy?

> To guard against bad bitbake versions (as BBPATH
> is unset, bitbake can be expected to be picked up from a generic PATH)
> it might be smart to introduce a variable in local.conf stating specific
> or minimum version requirements for bitbake.

  ... Ah, and it comes at the expense yet?

> Would there by any problems in extending bitbake calling convention in
> this way?

  Yes. Occam's blade. There's nothing to extend for. "man bash" will
make everyone who does it an expert not only in bitbake, but in Unix
way of doing stuff at all. After that, it will be much easier to
decide if something worth fixing, if yes, then why, and finally, how.

> /Esben




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Rod Whitby]

Paul Sokolovsky wrote:
> Hello Esben,
> Wednesday, November 21, 2007, 8:20:57 AM, you wrote:
> []
>>> The question is how to fix this problem correctly.
>>> One possibility would be that bitbake, if BBPATH is unset, issues a
>>> warning and scans the file system (starting from the $PWD) for a
>>> certain file (local.conf) in which BBPATH would be specified.
> 
>> Something like that would be nice. When bitbake finds BBPATH unset, it
>> traverses from $PWD to / to find a .bbenv (or some other filename, but
>> local.conf is probably not a good one), which can setup BBPATH,
>> PYTHONPATH, OEDIR or whatever env virables is used in the
>> conf/local.conf file.
> 
>   LOL. So, editing .bashrc is hard, while creating and editing some
> obscure file is easy?

The difference is that .bashrc is global for the the user, where as a
file can be local to each different build area that the user wants to
keep separate.

What we are discussing is session-local configuration vs
directory-tree-local configuration.  At the moment, bitbake uses some of
each, and that's the root of the problem.  The Makefiles are designed to
turn this into directory-tree-local configuration only.

-- Rod

Re: Getting Started -Makefile

[Esben Haabendal]

On Wed, 2007-11-21 at 19:57 +0200, Paul Sokolovsky wrote:
> Hello Esben,
> 
> Wednesday, November 21, 2007, 8:20:57 AM, you wrote:
> 
> []
> 
> >> The question is how to fix this problem correctly.
> >> One possibility would be that bitbake, if BBPATH is unset, issues a
> >> warning and scans the file system (starting from the $PWD) for a
> >> certain file (local.conf) in which BBPATH would be specified.
> 
> > Something like that would be nice. When bitbake finds BBPATH unset, it
> > traverses from $PWD to / to find a .bbenv (or some other filename, but
> > local.conf is probably not a good one), which can setup BBPATH,
> > PYTHONPATH, OEDIR or whatever env virables is used in the
> > conf/local.conf file.
> 
>   LOL. So, editing .bashrc is hard, while creating and editing some
> obscure file is easy?

No, they are very much the same. And that is not the issue here.

The issue is as Rod also describes, the possibility to switch between
different OE build setups by switching directory. Further on, my
proposal would not dictate you to be in a specific directory, ie. the
build dir, to make bitbake behave as expected, but allow you to go to
any subdir of the build dir and have the same behavior as with the
current .bashrc or ". ./setup-env" approach.

> > To guard against bad bitbake versions (as BBPATH
> > is unset, bitbake can be expected to be picked up from a generic PATH)
> > it might be smart to introduce a variable in local.conf stating specific
> > or minimum version requirements for bitbake.
> 
>   ... Ah, and it comes at the expense yet?

Nothing is free. And I am certain that if it turns out the be a real
problem that people depend on different specific bitbake versions (I am
sorry, I don't know if this is a common situation today...), then we can
find a solution.

> > Would there by any problems in extending bitbake calling convention in
> > this way?
> 
>   Yes. Occam's blade. There's nothing to extend for. "man bash" will
> make everyone who does it an expert not only in bitbake, but in Unix
> way of doing stuff at all. After that, it will be much easier to
> decide if something worth fixing, if yes, then why, and finally, how.

I really fail to see your point here. Are you meaning to say that the
current solution with setting environment variables in .bashrc or
setup-env makes anybody a Unix expert?  I believe that all the other
skills require to work with OE is more demanding, so that this is not a
good reason for any kind of in-convenience.

Best regards,
Esben

-- 
Esben Haabendal
Embedded Software Consultant, Dore Development ApS
Phone: +45 5192 5393  Email: eha@doredevelopment.dk

Re: Getting Started -Makefile

[Richard Purdie]

On Tue, 2007-11-20 at 10:21 +1030, Rod Whitby wrote:
> The challenge I put to yourself and a couple of other people from the OM
> core team in IRC a couple of weeks or months ago still stands:
> 
> Show how you can use bitbake such that you can cd into a build area, and
> type a *single* bitbake command to do a build, then cd into a different
> build area (with a different distro and machine) and type a *single*
> bitbake command to do a build there.  No other commands are allowed.
> 
> At the moment, you need to set many environment variables before bitbake
> can do it's job, and you need to reset them when you move into a
> different area to do a different build.  That's the reason why there are
> makefile wrappers around simple bitbake commands.
> 
> If we can fix the underlying problem (needing to type more than one
> command to build an image with bitbake), then I will fully support a
> move to get rid of all bitbake wrappers from all the Makefiles that I
> manage.
> 
> Instead of just saying that you won't tolerate something, how about
> understanding *why* that something is done, and then work together to
> improve the existing tools so that something no longer needs to be done
> cause the tools already cover that use case.

Would you agree that bitbake itself isn't painful to use? "bitbake xyz"
is just as simple as "make image" (or whatever)?

See my previous mail about how Poky handles this: "source script;
bitbake xyz". I realise this isn't the one stop shop you describe but I
think the fact bitbake is exposed to the user is a really positive move
and well worth the slight extra learning curve. The script being sourced
can even hint at the commands to run...

If the makefile worked like that, exposing the user to bitbake instead
of hiding it, most of the opposition to the makefile would be removed.

Cheers,

Richard

Re: Getting Started -Makefile

[Rod Whitby]

Richard Purdie wrote:
> Would you agree that bitbake itself isn't painful to use? "bitbake xyz"
> is just as simple as "make image" (or whatever)?

Yes, with the comment that the make command takes notice of a standard
directory structure, and does the right thing based on that, echoing
every lower-level command that it executes, as opposed to bitbake, the
operation of which depends upon whichever set of environment variables
the user happened to remember to source latest (or in most cases I've
seen, forget to source and therefore get confused when bitbake complains
about not being able to do anything).

> See my previous mail about how Poky handles this: "source script;
> bitbake xyz". I realise this isn't the one stop shop you describe but I
> think the fact bitbake is exposed to the user is a really positive move
> and well worth the slight extra learning curve. The script being sourced
> can even hint at the commands to run...

Um, the makefile *prints* *out* the exact bitbake commands that are
being run.  If it's so simple, then one would assume that people would
learn from that and start typing the commands themselves ...

> If the makefile worked like that, exposing the user to bitbake instead
> of hiding it, most of the opposition to the makefile would be removed.

Market forces prevail - if we improve the OE documentation and user
tutorials and ease of use, then people won't need the makefiles.  The
makefiles are an option they are mandatory - if the other options become
easier to use then  people will use them.  If the other options do not
become easier to use, then one might put forward a position that the
easiest to use option *should* prevail.

The OE documentation and wiki has the commanding position in teaching
new people how to access and use OE.  Note that *nowhere* in the OE wiki
or documentation are the makefiles mentioned.  If that commanding
position cannot be turned into a scenario where people run bitbake
directly rather than a Makefile, then one must question why that is not
the case, rather than just disparaging the Makefile and leaving the
users out in the cold.

-- Rod

Re: Getting Started -Makefile

[Koen Kooi]

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

Rod Whitby schreef:
>  Note that *nowhere* in the OE wiki
> or documentation are the makefiles mentioned. 

They are pretty much mandated in the nslu2 and openmoko wiki, which
covers nearly 100% of Makefile users. See a correlation?


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHQtNwMkyGM64RGpERAuZ4AJwMgrcZo+5QEjBLEV8gmgpNpRt8MwCglmxG
z47psRg5nvWo43ePVd7USI4=
=Jkrd
-----END PGP SIGNATURE-----

Re: Getting Started -Makefile

[Rod Whitby]

Koen Kooi wrote:
> Rod Whitby schreef:
>>  Note that *nowhere* in the OE wiki
>> or documentation are the makefiles mentioned. 
> 
> They are pretty much mandated in the nslu2 and openmoko wiki, which
> covers nearly 100% of Makefile users. See a correlation?

Yes, and I've given the technical reason why, and yet you continue to
ignore the technical discussion.

-- Rod

Re: Getting Started -Makefile

[Koen Kooi]

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

Rod Whitby schreef:

> Show how you can use bitbake such that you can cd into a build area, and
> type a *single* bitbake command to do a build, then cd into a different
> build area (with a different distro and machine)

Why are you using a different build area for that? That's unnecessary.
Just do something like

TMPDIR = "/OE/tmp/${DISTRO}"

in site.conf. If your distro is a bit behind the times and doesn't use
multimachine add:

INHERIT += "multimachine"

No need for seperate build areas. If you use angstrom you can even
switch C library ([e]glibc vs uclibc), as outlined in
http://www.angstrom-distribution.org/building-angstrom
You can even have per distro tweaks using include statements, but I'll
leave that as an exercise to the reader. No need for seperate build
areas. At all.


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHQq/MMkyGM64RGpERApx4AJwLiQrVBbGDGlrdVfN8P6TzUl5u+wCfZIH8
YaWoQ3YzbtknQqu5sJ44Ito=
=PlQ1
-----END PGP SIGNATURE-----

Re: Getting Started -Makefile

[Rod Whitby]

Koen Kooi wrote:
> Rod Whitby schreef:
>> Show how you can use bitbake such that you can cd into a build area, and
>> type a *single* bitbake command to do a build, then cd into a different
>> build area (with a different distro and machine)
> 
> Why are you using a different build area for that? That's unnecessary.

Um, when the MokoMakefile was created, it *was* necessary to have a
different build area.  Direct your statements to the maintainers of the
distributions in question, not to those who are trying to help the
end-users use those build systems.

Isn't the creator of the OpenMoko build environment an OE core team
member?  Does the OpenMoko build environment setup documentation follow
your prescription for TMPDIR and multimachine?

Physician, heal thyself.

-- Rod

Re: Getting Started -Makefile

[Koen Kooi]

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

Rod Whitby schreef:
> Koen Kooi wrote:
>> Rod Whitby schreef:
>>> Show how you can use bitbake such that you can cd into a build area, and
>>> type a *single* bitbake command to do a build, then cd into a different
>>> build area (with a different distro and machine)
>> Why are you using a different build area for that? That's unnecessary.
> 
> Um, when the MokoMakefile was created, it *was* necessary to have a
> different build area.  

No it wasn't. I've been using this setup since long before openmoko
existed. I started using it when I was comparing familiar and openzaurus
builds when Mickeyl was still OZ release master.

> Isn't the creator of the OpenMoko build environment an OE core team
> member?  Does the OpenMoko build environment setup documentation follow
> your prescription for TMPDIR and multimachine?

Mickey was and is an OE core developer, but all the other core members
have been appalled by the implementation of the OM env described in
their wiki (to mention a few: hardcoding BUILD_ARCH and replacing
/usr/bin/svn with a script).
As proven multiple times on the OE-devel list, the OM wiki has bad
practices for using OE. At the last OEDEM we coined 'Mo(c)kumentation'
to describe it.



- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHQtLAMkyGM64RGpERAimVAKCRGKb3XX5X3hK1OczvzMs16OAiEgCfbFfi
4QzzYg6Tzp+yXXoxkDfQRA0=
=6UN1
-----END PGP SIGNATURE-----

Re: Getting Started -Makefile

[Rod Whitby]

Koen Kooi wrote:
> Rod Whitby schreef:
>> Isn't the creator of the OpenMoko build environment an OE core team
>> member?  Does the OpenMoko build environment setup documentation follow
>> your prescription for TMPDIR and multimachine?
> 
> Mickey was and is an OE core developer, but all the other core members
> have been appalled by the implementation of the OM env described in
> their wiki (to mention a few: hardcoding BUILD_ARCH and replacing
> /usr/bin/svn with a script).

So are you saying that the very first OM wiki how-to-build documentation
(which predated any MokoMakefile) was written by someone other than
Mickey, and that Mickey did not agree with the public release of the
description of how to build OpenMoko using OE?  I find that incredulous.

> As proven multiple times on the OE-devel list, the OM wiki has bad
> practices for using OE. At the last OEDEM we coined 'Mo(c)kumentation'
> to describe it.

Yes, and you continue to disparage the OpenMoki wiki documentation,
instead of helping to fix it.

-- Rod

Re: Getting Started -Makefile

[Paul Sokolovsky]

Hello Rod,

Tuesday, November 20, 2007, 1:11:55 PM, you wrote:

> Koen Kooi wrote:
>> Rod Whitby schreef:
>>> Show how you can use bitbake such that you can cd into a build area, and
>>> type a *single* bitbake command to do a build, then cd into a different
>>> build area (with a different distro and machine)
>> 
>> Why are you using a different build area for that? That's unnecessary.

> Um, when the MokoMakefile was created, it *was* necessary to have a
> different build area.  Direct your statements to the maintainers of the
> distributions in question, not to those who are trying to help the
> end-users use those build systems.

> Isn't the creator of the OpenMoko build environment an OE core team
> member?  Does the OpenMoko build environment setup documentation follow
> your prescription for TMPDIR and multimachine?

  Well, I see the root of problem exactly here: a typical developer
produces personal/one-off scripts in huge quantities. Few of those
personal/one-off scripts even evolve into something used as multi-shot
and community-local scripts, sometimes.

  But if I'd post my local hack-scripts to the list as something opening
a whole new world, I'd be laughed at. And if I'd use a slightly
different language in the post, I'd be flamed for forcing my crap upon
other people. And that's exactly what happens in this thread.


> Physician, heal thyself.



> -- Rod


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: Getting Started -Makefile

[Florian Boor]

Hi,

HiKoen Kooi schrieb:
> No need for seperate build areas. If you use angstrom you can even
> switch C library ([e]glibc vs uclibc), as outlined in
> http://www.angstrom-distribution.org/building-angstrom
> You can even have per distro tweaks using include statements, but I'll
> leave that as an exercise to the reader. No need for seperate build
> areas. At all.

as soon as you are working with multiple builds in parallel or you want to
specify versions you need multiple build directories.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Getting Started -Makefile

[Rod Whitby]

Rod Whitby wrote:
> Koen Kooi wrote:
>> David Farning schreef:
>>> $make setup
>> nice
>>
>>> $make build-package-vim
>> $deity just killed a few hundred kittens.
>> At OEDEM we decided that we won't tolerate kindergarten-like,
>> hand-holding wrappers around bitbake. Typing 'bitbake vim' isn't rocket
>> science. To paraphrase Mickey: "If typing 'bitbake <foo>' is too hard,
>> you shouldn't be using OE".

The thing that I don't understand is that "bitbake <foo>" is eleven less
characters to type than "make build-package-<foo>", so the question we
should be asking is:

Why are people prepared to type ten extra characters every time they
want to build a package rather than using bitbake directly?

The answer to that question holds the key to the way forward on this issue.

Are the powers of persuasion of the various Makefile authors so great
that they can convince people to type more characters, even when the
documentation, wiki and tutorials provided by OE explicitly tell people
to use a command which involves typing less characters?

-- Rod

Re: Getting Started -Makefile

[Koen Kooi]

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

Rod Whitby schreef:

> Are the powers of persuasion of the various Makefile authors so great
> that they can convince people to type more characters, even when the
> documentation, wiki and tutorials provided by OE explicitly tell people
> to use a command which involves typing less characters?

As I pointed out in an earlier email: The nslu2 and openmoko wiki pretty
much mandate using the makefile.
I get the impression you deliberately try to confuse us by mentioning
openmoko on one hand and then pointing to the OE instead of the OM wiki.


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHQtyuMkyGM64RGpERAt9FAJ9DIQKZ/jVhhJsmFfJO46wZKpVSKgCfXz7/
RGCriw2n8sYMYQsscq9+vpE=
=wrmN
-----END PGP SIGNATURE-----

Re: Getting Started -Makefile

[Rod Whitby]

Koen Kooi wrote:
> Rod Whitby schreef:
>> Are the powers of persuasion of the various Makefile authors so great
>> that they can convince people to type more characters, even when the
>> documentation, wiki and tutorials provided by OE explicitly tell people
>> to use a command which involves typing less characters?
> 
> As I pointed out in an earlier email: The nslu2 and openmoko wiki pretty
> much mandate using the makefile.
> I get the impression you deliberately try to confuse us by mentioning
> openmoko on one hand and then pointing to the OE instead of the OM wiki.

And you continue to dodge the real question of what needs to be done to
bitbake to make it easier to use than a Makefile - it's already less
characters to type, why aren't people using it.

When you start to address the real question, and stop just disparaging
other development practices for the sake of it, then we can have a
serious discussion about this.

-- Rod

Re: Getting Started -Makefile

[Lorn Potter]

Rod Whitby wrote:

> And you continue to dodge the real question of what needs to be done to
> bitbake to make it easier to use than a Makefile - it's already less
> characters to type, why aren't people using it.

I can answer that.

Because make is more familiar to us. We have used it for years. No need 
to learn something new, and we can instantly get on with the job at 
hand, instead of reading web docs, and fighting with bitbake, etc. You 
see a makefile, you instantly know what to do, without having to spend 
30 minutes searching wiki's.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech

Re: Getting Started -Makefile

[Holger Freyther]

Am 19.11.2007 um 13:08 schrieb David Farning:

> This eliminates many of problems the new users have setting up bb
> and oe.  There is no need to know any thing about svn of monotone.

Hey,

this is the issue you want to solve? IMO developers should know about  
how to build software and this includes getting the source. I think  
it is no use in hiding OpenEmbedded and BitBake behind a GNU Makefile.

I have the feeling that the issue you want to solve needs to be  
solved by the distro/origanisation to provide a SDK so people can  
build software.

z.

PS: This doesn't change the fact that we need better documentation...

Re: Getting Started -Makefile

[Tobias Pflug]

On Mon, 2007-11-19 at 15:41 +0100, Holger Freyther wrote:
> Am 19.11.2007 um 13:08 schrieb David Farning:
> 
> > This eliminates many of problems the new users have setting up bb
> > and oe.  There is no need to know any thing about svn of monotone.
> 
> Hey,
> 
> this is the issue you want to solve? IMO developers should know about  
> how to build software and this includes getting the source. I think  
> it is no use in hiding OpenEmbedded and BitBake behind a GNU Makefile.
> 
> I have the feeling that the issue you want to solve needs to be  
> solved by the distro/origanisation to provide a SDK so people can  
> build software.
> 
> z.
> 
> PS: This doesn't change the fact that we need better documentation...

On first thought I completely agree. On second thought things often 
go a bit different in real-life real working environments in companies.
With the ever present "time=money" dogma in mind it helps to have some
means to easily set up a working environment. 

At some point however someone will have to set up a problem specific
build environment for the company/project/.. Integration work is a
must and can never be solved by OE. 

So to conclude .. I think there is no point in trying to hide complexity
because if you want to do serious work with OE it /will/ get complex.
However making the setup/installation easier is always a good thing. One
way to do that would be to provide nice up-to-date packages with
all necessary dependencies. Some stuff is available already from what
I recall .. "OE and your distro" on the wiki ... Keeping those packages
working and up-to-date would be helpful I suppose. I will probably
have to look into that soon as I need to provide an SDK for my company
soon.

Re: Getting Started -Makefile

[Lorn Potter]

Holger Freyther wrote:
> Am 19.11.2007 um 13:08 schrieb David Farning:
> 
>> This eliminates many of problems the new users have setting up bb
>> and oe.  There is no need to know any thing about svn of monotone.
> 
> Hey,
> 
> this is the issue you want to solve? IMO developers should know about  
> how to build software and this includes getting the source. I think  
> it is no use in hiding OpenEmbedded and BitBake behind a GNU Makefile.

well, me and lot of other developers disagree. Hence the popularity of 
the openmoko makefile.

Are you trying to make it easier or harder to generate file systems? 
Lots of developers do not have time to learn the symantics of 
bitbake/monotone, etc.

Anything that can make it easier to set up and build is needed. 
Otherwise it is just easier to build it from scratch.



-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech

Re: Getting Started -Makefile

[Richard Purdie]

On Tue, 2007-11-20 at 07:08 +1000, Lorn Potter wrote:
> Holger Freyther wrote:
> > Am 19.11.2007 um 13:08 schrieb David Farning:
> > 
> >> This eliminates many of problems the new users have setting up bb
> >> and oe.  There is no need to know any thing about svn of monotone.
> > 
> > Hey,
> > 
> > this is the issue you want to solve? IMO developers should know about  
> > how to build software and this includes getting the source. I think  
> > it is no use in hiding OpenEmbedded and BitBake behind a GNU Makefile.
> 
> well, me and lot of other developers disagree. Hence the popularity of 
> the openmoko makefile.
> 
> Are you trying to make it easier or harder to generate file systems? 
> Lots of developers do not have time to learn the symantics of 
> bitbake/monotone, etc.
> 
> Anything that can make it easier to set up and build is needed. 
> Otherwise it is just easier to build it from scratch.

I think Holger's point and the general feeling of other OE devs, me
included is that the current wave of makefiles hide too much. I had to
solve this problem with Poky and I did it with a script you source which
sets up a magic environment. I don't expect users to know/care about
what the script does. I do want users to end up typing "bitbake xyz"
though. Why?

Users end up realising that everything is either an SCM command ("svn
up" for Poky) or a bitbake one. Neither are complicated programs to
learn. Yes monotone is more complex than svn but all you really need to
know is "mtn pull;mtn up" and even then, understanding why there are two
commands actually teaches you something important about the SCM. Hiding
them from the user just creates a  phobia of using the real tools.

Cheers,

Richard

Re: Getting Started -Makefile

[Marcin Juszkiewicz]

Dnia wtorek, 20 listopada 2007, Richard Purdie napisał:

> Users end up realising that everything is either an SCM command ("svn
> up" for Poky) or a bitbake one. Neither are complicated programs to
> learn. Yes monotone is more complex than svn but all you really need to
> know is "mtn pull;mtn up" and even then, understanding why there are
> two commands actually teaches you something important about the SCM.
> Hiding them from the user just creates a  phobia of using the real
> tools.

And updating can also be handled by 'first step'. My setup-oe.sh script 
updates BitBake and OE, set env vars and put me into build dir.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

    The fact that no one understands you doesn't mean you're an artist.

Re: Getting Started -Makefile

[Mike (mwester)]

> From: "Richard Purdie" <rpurdie@rpsys.net>
>
> I think Holger's point and the general feeling of other OE devs, me
> included is that the current wave of makefiles hide too much. I had to
> solve this problem with Poky and I did it with a script you source which
> sets up a magic environment. I don't expect users to know/care about
> what the script does. I do want users to end up typing "bitbake xyz"
> though. Why?
>
> Users end up realising that everything is either an SCM command ("svn
> up" for Poky) or a bitbake one. Neither are complicated programs to
> learn. Yes monotone is more complex than svn but all you really need to
> know is "mtn pull;mtn up" and even then, understanding why there are two
> commands actually teaches you something important about the SCM. Hiding
> them from the user just creates a  phobia of using the real tools.
>
> Cheers,
>
> Richard

I know bitbake.  I use bitbake.  I debug bitbake (more often than I want to,
actually).

Yet I also type "make all" to build things.

Why?

Not because I have a "phobia of using the real tools."  Not because I'm
stupid.  Not because I'm philisophically opposed to bitbake.  It might
perhaps be because I'm so old that I have moss growing on me, and that I've
been typing "make <target>" since rocks were young and dirt was just
invented.  It's true that my brain thinks "bitbake <thing>" and my fingers
type "make <thing>".

I ask the OE team why are they are philosophically opposed to driving
bitbake with make?  Make has driven software development since near the dawn
of time.  Make has been used to set up environment variables, adjust for
unusual or tricky build environments, and generally to ease the life of a
developer for eons.  It works very well for its purpose.  So why would
anyone encourage a development approach that throws out such a useful tools
and forces a user to manually set environment variables, and remember an
obscure command to invoke a build?  Of course a serious developer should
know generally what goes on underneath, but that doesn't mean that they
should do all the steps manually!

Unless it is the intent to create a barrier to entry?

Mike (mwester)

Re: Getting Started -Makefile

[Marcin Juszkiewicz]

Dnia wtorek, 20 listopada 2007, Mike (mwester) napisał:

> I ask the OE team why are they are philosophically opposed to driving
> bitbake with make?  

I am ok with something like "make update" or "make setup" which will 
update BitBake/OE and prepare environment to do builds. But "make 
build-package-with-this-name" scares me as this overcomplicate things for 
me.

In time when OpenMoko used own makefile (OM-2007.1) I used it because it 
took all "you need this overlay" etc crap from me. But only to setup and 
update - I did builds with calling BitBake by hand (after sourcing 
generated "setup-env" script).

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

        What a strange game. The only winning move is not to play.
        		-- WOPR, "War Games"

Re: Getting Started -Makefile

[Holger Freyther]

Am 20.11.2007 um 16:32 schrieb Mike (mwester):
>
> Unless it is the intent to create a barrier to entry?

A couple of  groups I consider:

1.) People knowing what they do:
	-If they want to use a Makefile they should use it and I'm totally  
happy with that (Mike I count you here)

2.) System Integrators:
	-They should understand what bitbake is doing and what OE is doing.  
They will need it for doing their job. And a Makefile is not helping  
them, Documentation will help them. They will evolve to 1.) and can do  
what they want...

3.) Users of a Distribution (NSLu2, OpenMoko, Angstrom) that want to  
build:
       - It is a distribution decision on how they want to bootstrap  
people and a Makefile seems to work for them. And I'm totally fine and  
happy with that because in case of issues the distro support team will  
support the users.
       - E.g. familiar has a nice use of zenity/dialog for that.


4.) People that want to add a package/fix a package in OE:
       - Our documentation could be better and we rely on good support  
on mailinglists and irc. How to improve? Better documentation? Anyway  
I don't think a Makefile will help here...

5.) Makefile for OE:
     - What MACHINE to set, what DISTRO to set, what tweaks to add?  
Who is deciding that? E.g. with the current proposal it is qemux86 and  
angstrom. OpenEmbedded is more than Angstrom, more than qemux86 and  
you would have to write more wrappers to hide the configuration. But  
what we do is just postponing the exposure to Monotone, OE and BitBake  
and I don't think this is clever. So IMO and others it doesn't make  
sense to have a MasterMakefile for OE because we target so many  
different things and it would be utterly complex to always do the  
right thing. e.g. we could use the MasterMakefile of NSLu2 as a  
template and put that into contrib so distributions can decide to use  
that, but again for OE it just doesn't make sense.

    - Making it harder to entry? Actually I think it is partially  
true: I have the impression that a Makefile for OE attracts users that  
will do the following:

     make foo
      ... "ERROR: You need to apt-get install make"

   Random User: The Makefile doesn't work it says "ERROR: You need to  
apt-get install make". What should I do?

    <wearing OE hat>I want users that have basic reading and  
comprehension capabilities. And honestly I think I'm not asking for  
too much here.</wearing OE hat>


And the last words: If I'm in a project or a company targetting  
something special I will do number three and use Richards approach and  
write sourcable shell scripts for the configuration. But then again I  
can do that there because I know what I target and I know what my work  
mates are supposed to do/use. For OE as multipurpose meta data  
repository I believe a Makefile doesn't make sense (think of make  
MACHINE=neo DISTRO=foo build-package-foo).

I think the key is to differentiate and I hope I did that. So a  
Makefile, zenity script, sourceable shell scripts in a contrib/distro- 
decisions/ as a template pool might make sense...


love
    z.

Re: Getting Started -Makefile

[Koen Kooi]

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

Mike (mwester) schreef:

> I ask the OE team why are they are philosophically opposed to driving
> bitbake with make? 

Or making a Sconstruct for people used to scons or a Makefile.PL  for
people used to perl or a setup.py for people used to distutils, or a xml
file for people used to ant or a .jam file for people used to jam or ..
or .. or ..

you get the idea?


- --
koen@dominion.kabel.utwente.nl will go go away in december 2007, please
use k.kooi@student.utwente.nl instead.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHQxl7MkyGM64RGpERAhXoAKCHtwWEzYIgodHpXeCrKi7tPupxEQCcD4EC
F/P3WP5G6p3pydsh8Fe6Qzw=
=ZkVd
-----END PGP SIGNATURE-----

Re: Getting Started -Makefile

[Lorn Potter]

Mike (mwester) wrote:
> I ask the OE team why are they are philosophically opposed to driving
> bitbake with make?  

Perhaps because oe's predecessor - buildroot, used make. Someone deemed 
make not good enough to build filesystems, and they decided to try 
something new.

Have I go that right?


-- 
Lorn 'ljp' Potter
Software Engineer, Systems Group, MES, Trolltech

Re: Getting Started -Makefile

[Michael 'Mickey' Lauer]

Lorn Potter wrote:
> Mike (mwester) wrote:
>> I ask the OE team why are they are philosophically opposed to driving
>> bitbake with make?  

> Perhaps because oe's predecessor - buildroot, used make. Someone deemed
> make not good enough to build filesystems, and they decided to try 
> something new.

> Have I go that right?

Bingo! The candidate gets 100 free runs of the bitbake command. See my
other mail for details ;)

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

The truth about OE team being afraid of 'make' (was: Getting Started -Makefile)

[Michael 'Mickey' Lauer]

Mike (mwester) wrote:
> I ask the OE team why are they are philosophically opposed to driving
> bitbake with make?

Ok, seems now's a good time to tell you. Because that's where we came
from back in 2002 -- from a Makefile-centric buildroot called
OpenZaurus that didn't scale at all (which is inherent to the
buildroot approach).

We are so glad that by inventing OpenEmbedded and BitBake we have left
this stoneage of building distributions behind.

Getting back to the 'make' command reminds us of the painful past before we had
OE.

Then again, it could be just a paranoia of me, Chris Larson, and
Holger Schurig ;)

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: The truth about OE team being afraid of 'make' (was: Getting Started -Makefile)

[Chris Larson]

On Nov 21, 2007 6:28 PM, Michael 'Mickey' Lauer <mickey@vanille-media.de> wrote:
> Mike (mwester) wrote:
> > I ask the OE team why are they are philosophically opposed to driving
> > bitbake with make?
>
> Ok, seems now's a good time to tell you. Because that's where we came
> from back in 2002 -- from a Makefile-centric buildroot called
> OpenZaurus that didn't scale at all (which is inherent to the
> buildroot approach).
>
> We are so glad that by inventing OpenEmbedded and BitBake we have left
> this stoneage of building distributions behind.
>
> Getting back to the 'make' command reminds us of the painful past before we had
> OE.
>
> Then again, it could be just a paranoia of me, Chris Larson, and
> Holger Schurig ;)

GNU Make has some features now which it did not have then, that could
have made it slightly less painful to use for our work, but naturally
it wouldn't be worth going back to a more limited base now.  Back
then, it didn't support things like dependency on a file's existance
only, avoiding rebuilds when timestamps change, and there was no
'eval' to facilitate on the fly rule generation.  To summarize, make
just wasn't suitable back then, and it would be a great deal of work
to go back to it now, and it'd still be less flexible than what we
have today, and would suffer from portability headaches with make
versions.
-- 
Chris Larson - clarson at kergoth dot com
Dedicated Engineer - MontaVista - clarson at mvista dot com
Core Developer/Architect - TSLib, BitBake, OpenEmbedded, OpenZaurus