On 09/09/14 23:44, Rob Landley wrote: > 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.
To clarify: The issue here is that if a command is disabled in kconfig, its FLAG_* macros are all #defined to 0, so the compiler's constant propagation and dead code elimination see something like: if (toys.optflags & FLAG_X) blah(); See that FLAG_X is 0, thus anything & FLAG_X must be 0, thus if (0) and it can optimize away the call to blah(). (This is intentional to allow configured-out code to drop out without #ifdefs, but it does mean that shared infrastructure can have functionality removed by kconfig if it depends on a specific command's flags.) (Even tinycc has _this_ level of constant propogation and optimization, so I feel I can rely on the compiler being able to do that much.) But if I resolve these dependencies by _enabling_ more than one command when doing a single build, the toy_list[] array isn't guaranteed to be length 1, thus I can't just grab the first entry unconditionally and avoid the multiplexer code. One fix is to work out a static offset to the command I want, but that has the downside that the other command_main() functions would have function pointers listed in toy_list[] and even though those function pointers are never used (the only user of toy_list[] dereferences a single static offset to get the one entry it's interested in), the compiler may not be smart enough to know it can optimize out those other command_main() functions and the code only they ever call. So... unresolved design issue I'm still chipping away at. The single builds weren't a priority before, so I didn't work out the details... Rob (Probably what I should do is separate toy_list[] generation from flag generation, so I can guarantee a single element toy_list[] when doing single builds, even if more than one kconfig entry is enabled as far as flags.h is concerned. But that's not for _this_ release...) _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
