Re: ARMv4-support in armel/squeeze?
On Thu, Dec 30, 2010 at 4:52 PM, Martin Guy <martinwguy@gmail.com> wrote:
> On Sun, Dec 19, 2010 at 9:30 PM, Wookey <wookey@wookware.org> wrote:
>> Does the
>> popularity-contest info record any CPU details? It would be helpful
>> for having some idea of the mix currently in use.
>
> It doesn't. I suggested this to its maintainer a few months ago, and
> they agreed that it would be useful.
>
> On Sun, Dec 19, 2010 at 10:04 PM, Luke Kenneth Casson Leighton
> <lkcl@lkcl.net> wrote:
>> * i remember neil said he spent months - almost a year - on the armel port
>
> "Neil"? I spent 2006 working to bootstrap the armel port, of which the
> first 6 months were getting a working EABI cross-compiler (partly
> because the emdebian crowd, who seemed to know more about it, urged me
> to; in reality you have to build Debian packages natively) and the
> last 6 months were spent doing exactly the circular dependency
> workarounding that has been described here.
jeezus. what a total waste. sorry, not of your work, but a total
waste that this wasn't automated back then, so that konstantinous
didn't have to completely re-duplicate it, from scratch.
> I got to 91 of the 114
> required packages and these were published by Wookey in November.
> Lennert Buytenhek then completed it in two months. Who's Neil?
sorry, martin - faulty memory!
>> * each and every time someone does a new port, all the knowledge and
>> expertise is re-learned, re-discovered... and then lost.
>
> I asked the same kind of question back then. The answer is that you
> have to get to a point where you can natively build the 114 packages
> that you need to be able to natively build packages (both those and
> others) and the most convenient mechanism to do that varies according
> to the available resources, for example other OS's using the same ABI
> that can be Debianized sufficiently to fool package builders into
> thinking they are running on Debian. This part is different for each
> port.
> However, I agree that some kind of guide would be useful to future porters
i was thinking more in terms of a totally automated, completely
scripted "guide". (then by utilising something like the bitbake
override mechanism, any exceptions and differences between the
architectures can be done very very simply, through the bitbake
combination of python + script-auto-generation).
you have to bear in mind that "future porting" *used* to be very
uncommon an occurrence (as if doing it 14 times is "uncommon")
but with the massive explosion in compiler options for ARM processors
alone, the process of "porting" now becomes a massive headache.
114 packages, all done by hand, and the effort was totally thrown
away. i'm deeply impressed that you did it, and just as equally
unimpressed that the work wasn't recorded in a scriptable,
reproduceable manner. [criticise and "blame" me for saying that if
you wish - it won't change anything]
l.
Reply to: