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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
