Heath Holcomb wrote: > The i586 arch is only an example for the how-to. Any x86 after i386 > should work fine (i386, i486, i586, i686), just change the GCC arch type > in /etc/make.conf.
OK I got it. > I'm not a programmer, just an hardware engineer, but I have done some > light programing and I have found QT to be the easier tool kit to use. > One interesting thing about embedded QT is that the GUI can talk > directly to a framebuffer, thus avoiding X and make your memory and > storage "footprint" much smaller. If you want to close source your > application, QT can be expensive. Well, Please do not take this question, the wrong way, but, as a firmware engineer, I've been exposed (primarily on the windows side) to dozens of firmware development semantics for all sorts of SOCs, uP, DSP and such. I'm sick of it all. I spend more time learning howto, than I do 'doing' code development.... With that apology as a basis for this question, Why are you guys not just developing a 'plug-in' for Eclipse that covers what embedded gentoo (and GNAP) and such require? FreeScale and much of the semiconductor world seem to be going that direction. Many of the Semiconductor vendors are rushing to build BSP that just plug into Eclipse. It would seem to me that if this approach is followed, then after a while, it becomes 'cookie cutter' for all sorts of open source embedded projects....... Granted, I have not done this (yet), but I'm very interested in participating in an effort to develop a plugin for Eclipse that encompasses what is need for a given embedded project. Embedded Gentoo seems to be ripe for a such experimentation. Hopefully, you will understand that this is not a criticism, but, a question from somebody that is genuinely frustrated with the menagerie of 'howtos' for embedded development. I guess I'm looking for the the 'Holy Grail' of firmware development and I do like Gentoo and the (hope of) Eclipse quite a lot..... I've even used Monta Vista's embedded linux offering on a DSP, and it is a KLUDGE, at best. I also understand that one needs a well documented, methodical approach to firmware development, before anyone can begin to package such a method into something like an eclipse plugin. Anyway thanks to you and mike for all of the information, and I do apologize, if I seem dense. James -- [EMAIL PROTECTED] mailing list
