[Aboriginal] Thoughts on xargs and aboriginal

Rob Landley rob at landley.net
Fri Jan 6 05:08:20 PST 2012


On 01/05/2012 04:28 PM, James McMechan wrote:
> 
> I was reading your http://landley.net/notes.html and saw the weirdness
> you were having with xargs' command line options for toybox
> As you said the most commonly used option -0 is not part of the 
> standard I think it is claimed as a GNU extension, it seems oddly useful 
> to be GNU though.

It's really a "linux extension".  The Linux users have been using the
gnu tools and push stuff upstream into them.  The FSF is really big into
taking credit for other people's ideas.

> It occurred to me that having a option like 
> TOYBOX_LOG_WEIRD_POSIX_FLAGS
> might be handy, rather than implementing the full standard on the first 
> pass, make toybox's option parsing know about all the POSIX flags but 
> just log them and their args (or the whole command line) to a file and 
> report failure.

It already reports failure on unknown optinos, and I have the
record-commands.sh wrapper that gives me a log of the full command lines
called for each command, so I can already get this.

> This might make "mind-bogglingly strange" a problem for a later
> date and the log file could be used like record-commands.sh to find
> what oddball option someone is actually using, who knows -I might not
> turn up until someone is compiling the ancient CDE window manager
> on a cell phone...

A lot of this happens anyway.  What I'm really looking at is "what's
involved in claiming posix compliance".

I want to do small and simple implementations of the commands, and that
basically means figuring out everything it should do up front rather
than bolting on features one at a time.  (Getting new features to share
code with older features usually means rewriting the older features'
implementation to provide at least some of the new stuff too.)

> busybox would not be my first choice for an alternate implementation 
> swapping uClibc for musl or glibc or one of the other C libraries might
> be a better choice, several are available even if only for a architecture 
> or two.  When testing the infrastructure for gcc-isms uClibc-isms ld-isms
> etc. it would seem to be ok to test with only a architecture or two just to
> ring out the gotchas and make sure things are mostly portable.

I'm redoing toybox anyway, to replace android toolbox.  It's not driven
by aboriginal, I'm just using aboriginal to test it.  (Busybox works
fine at the moment for aboriginal linux.)

  http://landley.net/notes-2011.html#13-11-2011

> Of course the compiler is a problem gcc-isms have crept in especially in
> the make dependency mess rather than using a correct make file to build the
> global directed graph, we use a compiler option to partially compile every
> file to produce a list of its includes to be used by make to determine if
> the file needs to be compiled, but since the makefiles are called recursively
> it may need another pass at the end to check if the other directories have made 
> a update after this pass was checked. see aegis.sourceforge.net/auug97.pdf
> This I seem to remember was the reason that tcc could not compile the kernel
> last time I checked.  pcc, Clang/llvm, icc and tcc (after the dep phase) have 
> been reported to compile the kernel, and so I would expect could compile 
> aboriginal and could be used to ring out those gotchas.

I still need to do
http://lists.celinuxforum.org/pipermail/celinux-dev/2009-December/000217.html

Remember, I had a tinycc fork, when the original repo had been dead for
a year and a half.

  http://landley.net/code/tinycc

When my fork revived interest in the project, Fabrice Bellard handed off
maintainership of the original dead branch to a windows developer who
said he didn't understand the work I'd done and cherry picked a few
commits to the original CVS branch and then continued on from there.
Third party contributions (such as x86-64 support) went to the original
branch that had the longer history and the tinycc.org domain name (and
which lwn.net covered each new release of, which it never did for my
version because it wasn't "official".)

The end result is that my project was overshadowed to the point I
stopped wanting to do it, and the original version is no closer to
building an unmodified linux kernel than it was when tccboot came out in
2004, and never will because the windows developer running it is only
interested in making a free windows compiler.

> Regarding the mini-busybox config I was using, I just wanted to be able to
> recompile aboriginal under itself I have no direct need for LFS support, I can
> after all compile busybox with defconfig under a running aboriginal setup.
> Hey, vi and shell history are not something used in aboriginal's build process.
> 
> I note that linux 3.2 is now out I look forward to aboriginal 1.1.1

Yesterday I kicked off a test build on a 16-way server borrowed from
Funtoo, but haven't had a chance to check back in yet (work deadline
today).  I need to adjust one of the perl removal patches to apply
without fuzz, and yank the sparc fix that got merged upstream (yay!),
and regression test the LFS build on all the targets.

I should have something out this weekend.

Rob

 1325855300.0


More information about the Aboriginal mailing list