The fact some of more visible and important of the OE folks seem unwilling to acknowledge this does them very little credit.
That was the point of my earlier post - currently, OE does keep all of the source and build directories after building everything, however it could be altered very simply to remove these - which would mean that the size would drop down to the same as a standard cross-toolchain (inc dependant libs as these would be needed anyway) + sizeof(bitbake & oe files) - so not significantly larger than a pure binary toolchain. There is still be a one-off requirement to build the toolchain, which would add a time penalty, but for me this is not an issue as I know exactly what the toolchain is doing, what patches it contains, etc.
I'm not contesting the fact that currently you need a fair bit of disk space to run OE, just the fact that the majority of this disk space is not actually used, it's just sat there containing already built files, much the same as would happen if you used plain configure, make & make install to build and install the cross-toolchain and libs by hand - and therefore OE is not nearly as terrible as it's made out to be by guylhem.
I, for one, would want to keep the source available locally (though in this day and age of fast, always on internet, that's not such a major issue), but it might well be worth while removing the build directories to cut down the disk space requirement after each package has been built, staged and packaged.
It's a valid point, but equally as most people have very large hard disks these days my understanding is that it probably wasn't a major priority. The major priority is to speed up BB/OE and cut memory useage, and I understand this has now been achieved. For those with disk size constraints, then looking into the additional 'inherit' flag as shown in hrw's post may be worthwhile.
further... since the repositories are a moving target, to build a current app, one might very well be in the position of having to build an entire image to match the versions of the app and its dependencies.
Yes and no, if the app in question depends on a CVS components then it will be downloaded and compiled again (unless you set a specific CVS date, for the app or globally), and if you update the package repository (the .bb files), any which have changed will be rebuilt (I think), but this is not normally a major thing, and if you want to stay with the files for a given release/date, then you just use the repository from that day with the appropriate CVS date set.
To go with this is a seeming unshakeable orthodoxy..a sense that anything done with by or todo with OE is inherently, naturally and imperatively right and best.
It's just that it really is rather a useful tool, which makes life vastly easier that cross-compiling the old way with a binary toolchain - I've done both, OE is easier and significantly cleaner IMHO. All that that aside, I understand that going on about something often has the opposite effect to that intended - it annoys people and drives them away, however this thread was partly having a go at the way BB/OE operates, so I think it's fair to go over it once more
The idea there is much by way of politics regarding oses for a device owned by so few is, in itself, pretty damned funny.
Not funny, a bit of a shame really, we ought to cooperate more, no matter which GUI/buildsystem we are using, rather than constantly bickering. In fact this general bickering has started to annoy me quite severely - I can see now how people could easily drift away.
Regards,
Si
