From: Esben Haabendal <eha@doredevelopment.dk>
To: Paul Sokolovsky <pmiscml@gmail.com>
Cc: openembedded-devel@openembedded.org
Subject: Re: Getting Started -Makefile
Date: Thu, 22 Nov 2007 09:40:50 +0100 [thread overview]
Message-ID: <1195720850.20614.13.camel@localhost> (raw)
In-Reply-To: <1496857094.20071121195713@gmail.com>
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
next prev parent reply other threads:[~2007-11-22 19:47 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-19 12:08 Getting Started -Makefile David Farning
2007-11-19 14:33 ` Koen Kooi
2007-11-19 23:51 ` Rod Whitby
2007-11-20 9:12 ` pHilipp Zabel
2007-11-20 17:57 ` Tim Bird
2007-11-20 20:00 ` Cliff Brake
2007-11-20 20:38 ` Philip Balister
2007-11-20 23:25 ` Florian Boor
2007-11-21 2:24 ` Paul Sokolovsky
2007-11-21 3:38 ` Rod Whitby
2007-11-21 2:24 ` Paul Sokolovsky
2007-11-21 5:44 ` Rod Whitby
2007-11-21 17:45 ` Paul Sokolovsky
2007-11-22 1:35 ` Michael 'Mickey' Lauer
2007-11-22 4:20 ` Lorn Potter
2007-11-22 8:14 ` Esben Haabendal
2007-11-23 1:05 ` Lorn Potter
2007-11-21 17:58 ` Tim Bird
2007-11-21 18:29 ` Paul Sokolovsky
2007-11-21 23:17 ` Rod Whitby
2007-11-22 0:44 ` Tim Bird
2007-11-22 20:29 ` Paul Sokolovsky
2007-11-21 19:32 ` Philip Balister
2007-11-21 19:32 ` Philip Balister
2007-11-20 21:16 ` Rod Whitby
2007-11-21 6:20 ` Esben Haabendal
2007-11-21 17:57 ` Paul Sokolovsky
2007-11-21 23:04 ` Rod Whitby
2007-11-22 8:40 ` Esben Haabendal [this message]
2007-11-20 9:39 ` Richard Purdie
2007-11-20 11:06 ` Rod Whitby
2007-11-20 12:30 ` Koen Kooi
2007-11-20 21:20 ` Rod Whitby
2007-11-20 9:58 ` Koen Kooi
2007-11-20 11:11 ` Rod Whitby
2007-11-20 12:27 ` Koen Kooi
2007-11-20 21:19 ` Rod Whitby
2007-11-20 14:39 ` Paul Sokolovsky
2007-11-20 23:20 ` Florian Boor
2007-11-20 11:44 ` Rod Whitby
2007-11-20 13:10 ` Koen Kooi
2007-11-20 21:11 ` Rod Whitby
2007-11-20 23:06 ` Lorn Potter
2007-11-19 14:41 ` Holger Freyther
2007-11-19 18:32 ` Tobias Pflug
2007-11-19 21:08 ` Lorn Potter
2007-11-20 9:33 ` Richard Purdie
2007-11-20 10:46 ` Marcin Juszkiewicz
2007-11-20 15:32 ` Mike (mwester)
2007-11-20 17:04 ` Marcin Juszkiewicz
2007-11-20 17:29 ` Holger Freyther
2007-11-20 17:29 ` Koen Kooi
2007-11-20 23:12 ` Lorn Potter
2007-11-22 1:32 ` Michael 'Mickey' Lauer
2007-11-22 1:28 ` The truth about OE team being afraid of 'make' (was: Getting Started -Makefile) Michael 'Mickey' Lauer
2007-11-22 3:15 ` Chris Larson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1195720850.20614.13.camel@localhost \
--to=eha@doredevelopment.dk \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
--cc=pmiscml@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.