[oe] Getting Started -Makefile

Paul Sokolovsky pmiscml at gmail.com
Wed Nov 21 18:29:38 UTC 2007


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 at gmail.com





More information about the Openembedded-devel mailing list