[Toybox] [Issue] - single build

Rob Landley rob at landley.net
Tue Sep 9 21:44:11 PDT 2014


On 09/04/14 22:32, Ashwini Sharma wrote:
> Hi Rob,
> 
> When doing a single build toy_list is populated with the command to be built
> and all it __aliases__ in the chronological ascending order.

I've checked in a partial upgrade to the infrastructure, it now
determines which C files to build by grepping for the NEWTOY/OLDTOY
macros that enable the commands in question.

However, some commands depend on other commands to be enabled. In some
cases the "depends on" can be removed from kconfig, but in others (such
as cp/mv/install) one command calls another command's infrastructure
across flag contexts. Or in the case of id/groups/logname they all work
in ID's flag context.

What I need to do is count how many *TOY() macros there are, make sure
the relevant ones are enabled (working _backwards_ through the depends
on, treating them as selects), sort the enabled commands alphabetically
(the build infrastructure does that for the binary search), and then
apply an offset to the array for the element we're using. (The offset
would usually be 0, but in cases where we can't avoid building more than
one command...)

(I note that there's some sort of historical issue where a multiplexer
can get confused, possibly if you have a scriptfile.sh that starts with
#!/bin/sh it sets argv[0] to scriptfile.sh instead of sh? I don't
remember. I do remember that the ability to build _without_ the
multiplexer is sometimes useful.)

Anyway, I'm doing design work to address this, but my current path to a
solution is more complicated than I'd like and I think I need to do more
thinking to simplify it further. I'm doing a pass examining the "depends
on" entries to see what the various cases are. Fixing this properly
almost certainly gets bumped to next release, but the basic cleanup
helps implement smbmount/nfsmount more simply (as additional commands
living in mount.c).

Rob

 1410324251.0


More information about the Toybox mailing list