> Since we are committing to uClibc (I have no complaints and am in complete
> agreement, except....) that raises a new issue. Well, not entirely new but an
> issue nonetheless. Familiar is now trying to krack down on developers and
> contributors to provide links to their source code used to make their current
> binary programs. The downside is that without the special patches and what
> not, alot of useful and great programs can not be ported readily to uClibc.
> Not saying that this is an impossibility, just saying that how do we design
> the ebuild to port current gentoo applications to fit and function in our
> embedded environments. Not all PDAs have the same screen size and memory
> constraints as noted in an earlier post. As memory is an important factor, it
> shouldn't be a penalty for those with bigger memory and displays. There
> should be a tool that works like genmenu, in which where you use this program
> (let us call it "genembedconf") to set the parameters for your particular
> build of a embedded system (ie the HP iPAQ H3955 is a 400MHz Intel XScale
> PXA250 hwhich has 32MB flash ROM, 64MB SDRAM, and 240x320 16-bit display.)
> We would want it to be compiled for a pxa and have all apps be ported to a
> display size of 240x320 with rotation capability. On the other hand, Sharp
> Zaurus C-7[56]0 display is 640x480 with 128MB of storage (of which 64MB is
> always for storage), and it's hardware processor is a Intel XScale PXA255.
> Then, of course, there is the ARM. So creating an gentoo embedded
> configuration tool I think would simplify creating cross-compiling toolchains
> and target-specific compiled code. I hope I conveyed my thoughts clearly
> enough so that everyone understands what I am talking about. As I have been
> up for far too long to mention and am now in dire need of some much needed
> sleep.

I don't see the need for a configuration tool. All you have to set are
CFLAGs and chose a libc, a choice which will be influenced by the amount
of memory on the device. Screen resolution has little effect when
building the package, unless it has multiple front ends, such as a QT
front end, a GTK one, a QT/E one, and the list goes on. In such cases I
feel USE flags should be used to determine which front ends are built. I
have yet to see applications with built in rotation. Environments such
as OPIE or I'm sure X handle this AFAIK. You use the same toolchain for
building ARM and PXA binaries, just with different CFLAGS(and obviously
the toolchain has to support PXA, but it is not a separate toolchain).
Just my 2 cents,
--
Abhishek Amit <abhishek@g.o>