Discussion:
[PATCH] Add the current state of AOSP to the roadmap.
(too old to reply)
enh
2018-10-04 21:01:25 UTC
Permalink
---
www/roadmap.html | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)

diff --git a/www/roadmap.html b/www/roadmap.html
index 2d562ec..0107a31 100755
--- a/www/roadmap.html
+++ b/www/roadmap.html
@@ -33,6 +33,7 @@ and progress towards implementing it.</p>
<li><a href=#sigh>Linux "Standard" Base</a></li>
<li><a href=#dev_env>Development Environment</a></li>
<li><a href=#android>Android Toolbox</a></li>
+<li><a href=#aosp>Building AOSP</a></li>
<li><a href=#tizen>Tizen Core</a></li>
<li><a href=#buildroot>buildroot</a></li>
<li>Miscelaneous: <a href=#klibc>klibc</a>, <a href=#glibc>glibc</a>,
@@ -358,6 +359,49 @@ chrt dd expr getfattr* lsof modprobe more
setfattr* tar tr traceroute
mtools genvfatfs mke2fs gene2fs
</b></blockquote>

+<hr />
+<h2><a name=aosp /><a href="#aosp">Use case: Building AOSP</a></h2>
+
+<p>The list of external tools used to build AOSP is
+<a href="https://android.googlesource.com/platform/build/soong/+/master/ui/build/paths/config.go">here</a>.</p>
+
+<blockquote><b>
+awk basename bash bc bzip2 cat chmod cmp comm cp cut date dd diff dirname du
+echo egrep env expr find fuser getconf getopt git grep gzip head hexdump
+hostname id jar java javap ln ls lsof m4 make md5sum mkdir mktemp mv od openssl
+paste patch perl pgrep pkill ps pstree pwd python python2.7 python3 readlink
+realpath rm rmdir rsync runalarm sed setsid sh sha1sum sha256sum sha512sum
+sleep sort stat tar tail tee todos touch tr true uname uniq unix2dos unzip
+wc which whoami xargs xmllint xxd xz zip zipinfo
+</b></blockquote>
+
+<p>The following are already in the tree and will be used directly:</p>
+
+<blockquote><b>
+awk bzip2 jar java javap m4 make python python2.7 python3 xz
+</b></blockquote>
+
+<p>Subtracting what's already in toybox (including the following toybox toys
+that are still in pending: <code>bc dd diff expr gzip lsof tar tr</code>),
+that leaves:</p>
+
+<blockquote><b>
+bash fuser getopt git hexdump openssl perl pstree rsync runalarm sh todos
+unzip xmllint zip zipinfo
+</b></blockquote>
+
+<p>For AOSP, zip/zipinfo/unzip are likely to be libziparchive based. The only
+use of perl is building the kernel, runalarm is just for the Mac, all todos
+callers will use unix2dos instead if it's available. git/openssl/xmllint seem
+like they should just be brought in to the tree. That leaves:</p>
+
+<blockquote><b>
+bash fuser getopt hexdump pstree rsync
+</b></blockquote>
+
+<p>(Why are fuser and pstree used during the AOSP build? They're used for
+diagnostics if something goes wrong.)</p>
+
<hr />
<h2><a name=tizen /><a href="#tizen">Use case: Tizen Core</a></h2>
--
2.19.0.605.g01d371f741-goog
Rob Landley
2018-10-04 22:29:58 UTC
Permalink
Post by enh
+<p>For AOSP, zip/zipinfo/unzip are likely to be libziparchive based. The only
+use of perl is building the kernel, runalarm is just for the Mac, all todos
What perl do you still need? I've submitted patches to remove all the perl from
kernel builds I've done, and they've all been merged by this point. The most
recent was:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6cea14f55474

Rob
enh
2018-10-04 22:41:45 UTC
Permalink
+someone who might be able to give specifics, but i expect the answer
is "that will be great in 3 years, but we're still building 3.10 and
4.4 and ..." :-/

(but thanks for fixing that!)
Post by Rob Landley
Post by enh
+<p>For AOSP, zip/zipinfo/unzip are likely to be libziparchive based. The only
+use of perl is building the kernel, runalarm is just for the Mac, all todos
What perl do you still need? I've submitted patches to remove all the perl from
kernel builds I've done, and they've all been merged by this point. The most
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6cea14f55474
Rob
Rob Landley
2018-10-05 02:32:16 UTC
Permalink
Post by enh
+someone who might be able to give specifics, but i expect the answer
is "that will be great in 3 years, but we're still building 3.10 and
4.4 and ..." :-/
I built those versions without perl. I started maintaining perl removal patches
when Peter Anvin added perl as a build dependency in 2.6.28 or so back in 2008.

https://lwn.net/Articles/313348/

And built every kernel version since then without perl, and resubmitted perl
removal patches to the kernel more or less annually for the next 5 years. The
3.9 versions would be the 3 linux-noperl*.patch files in:

https://github.com/landley/aboriginal/tree/871b5d5bae2fe16f9ed9eb7172643429f8eafba7/sources/patches

And I finally got them merged in 2013:

https://lkml.org/lkml/2013/2/27/396

Ala:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?0c0de199ce1f

Git describe says that commit was in the run up to v3.10. (v3.9-2170-hash) which
explains why 3.9 is the last full set in that tree.

Unfortunately only 2 of my 3 patches went in because Peter Anvin replaced one
perl dependency with a bc dependency. He's consistently like that for some
reason: he blocked my third patch and made sure busybox _couldn't_ build an
unmodified kernel. I dunno why he wants that to be the case. I blogged about it
at the time, http://landley.net/notes-2013.html#18-05-2013 and continued to
maintain a C version of the stuff he did in bc, but... bc _is_ technically
posix, and you know the history since. :)

Perl would occasionally crop up again, and I'd shoot it down again when it did, ala:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d69911a68c86

The link last message was just the most _recent_ time perl has resurfaced. (And
perl didn't get cleaned out of various sub-features, like raid hash calculation,
until later because I wasn't building those in my aboriginal or mkroot projects.
But removing any given instance of perl generally isn't that hard to do, and
other people submitted patches for the remaining corner cases once I got the
ball rolling.

Seriously, point me at a kernel source tree and a .config, and I'll try to build
it without perl. I spent _years_ doing that...

Rob

P.S. I haven't been removing perl from things like "perf" or
"scripts/get_maintainer.pl" for the same reason I'm not trying to remove the
curses dependency from menuconfig. A development machine and a build machine are
two different things, the kernel _build_ is what should be free of perl.
Development can offer eclipse plugins for all I care...
enh
2018-10-05 19:57:09 UTC
Permalink
Post by Rob Landley
Post by enh
+someone who might be able to give specifics, but i expect the answer
is "that will be great in 3 years, but we're still building 3.10 and
4.4 and ..." :-/
I built those versions without perl. I started maintaining perl removal patches
when Peter Anvin added perl as a build dependency in 2.6.28 or so back in 2008.
https://lwn.net/Articles/313348/
And built every kernel version since then without perl, and resubmitted perl
removal patches to the kernel more or less annually for the next 5 years. The
https://github.com/landley/aboriginal/tree/871b5d5bae2fe16f9ed9eb7172643429f8eafba7/sources/patches
https://lkml.org/lkml/2013/2/27/396
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?0c0de199ce1f
Git describe says that commit was in the run up to v3.10. (v3.9-2170-hash) which
explains why 3.9 is the last full set in that tree.
Unfortunately only 2 of my 3 patches went in because Peter Anvin replaced one
perl dependency with a bc dependency. He's consistently like that for some
reason: he blocked my third patch and made sure busybox _couldn't_ build an
unmodified kernel. I dunno why he wants that to be the case. I blogged about it
at the time, http://landley.net/notes-2013.html#18-05-2013 and continued to
maintain a C version of the stuff he did in bc, but... bc _is_ technically
posix, and you know the history since. :)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d69911a68c86
The link last message was just the most _recent_ time perl has resurfaced. (And
perl didn't get cleaned out of various sub-features, like raid hash calculation,
until later because I wasn't building those in my aboriginal or mkroot projects.
But removing any given instance of perl generally isn't that hard to do, and
other people submitted patches for the remaining corner cases once I got the
ball rolling.
Seriously, point me at a kernel source tree and a .config, and I'll try to build
it without perl. I spent _years_ doing that...
sorry, dwillemsen investigated and it turned out that our guess was
completely wrong... it was actually a script to generate payloads for
the A/B OTA system. switched to python (which we're already committed
to prebuilts for) by
https://android-review.googlesource.com/c/platform/system/update_engine/+/779514.

but, yes, please keep up the good work keeping perl out of the build :-)
Post by Rob Landley
Rob
P.S. I haven't been removing perl from things like "perf" or
"scripts/get_maintainer.pl" for the same reason I'm not trying to remove the
curses dependency from menuconfig. A development machine and a build machine are
two different things, the kernel _build_ is what should be free of perl.
Development can offer eclipse plugins for all I care...
Loading...