Re: BuildRoot like tool
Hello Allen,
> I believe there are 2 parts to this problem.
> 1. Create the initial root file-system which is "bootable" by the target
> 2. Build additional applications to add to the initial root file-system.
This would be done by installing the generated packages on the development
host. This should create a chroot which you can generate any filesystem you
like from (cramfs, jff2, ext2) or use it as an NFS mount.
This also gives you the possibility to use the packages on target if you wish
(like on a PDA for example)
Of course there would be a base install which includes the packages you need
for a minimal boot. (reduced libc/ uclibc and busybox, dev and init/etc files)
> The reason for the separation is the difficulty of cross compiling some
> packages. It may be possible that we need to punt and compile some
> packages on the target. (or in an emulated environment)
We could maybe use scratchbox for those difficult packages, for example
> > Actually E. Andersen managed to build a full debian in there (but with
> > uclibc)
> > but only natively. If we can do the same with the modified tools we
> > could
> > maybe do this natively and cross-compiled.
>
> If this project intends to ignore "deeply" embedded systems, I am very
> disappointed. In that case this is little more than supporting Linux on
> Mac or Sun with the elimination of documentation.... Not very useful
> for me.
That is where the emdebian info would be usefull for. Not only solving
cross-compilation problems, but also further reduce the footprint if possible.
The default "throw away docs" procedure enables us to build smaller Debian
packages easily and quickly and is just there for more rapid software
availability.
IMHO for deeply embedded systems you can better turn to uclinux. (this depends
of course on what you mean with deeply embedded)
> I was happy to see that uclibc was used in Stag for ARM processors. I
> personally believe that we should standardize on uclibc, or something
> similar, with the goal of achieving the smallest footprint possible.
It was also the basic idea to do the compiling for uclibc by default. Which is
possible as Andersen has proved.... But leave the flexability to use glibc or
something else if you wish. If we would do the compiling in a uclibc
environment like Andersens buildroot we would at the same time (without
reworked packages) reduce size by removing crufty docs and using a smaller
libc. After this we could refine the packages with the emdebian/rules instead
od debian/rules.
So I hope you do not feel left out :-) This is a more thought out development
of Stag.
regards,
Philippe
| Philippe De Swert -GNU/linux - uClinux freak-
|
| Stag developer http://stag.mind.be/
| Emdebian developer: http://www.emdebian.org
|
| Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt)
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)
| Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/
-------------------------------------------------------
NOTE! My email address is changing to ... @scarlet.be
Please make the necessary changes in your address book.
Reply to: