Am 20.07.2017 12:17, schrieb Denys Vlasenko: > On Wed, Jul 19, 2017 at 6:38 PM, Kang-Che Sung <[email protected]> wrote: >> (https://git.busybox.net/busybox/commit/?id=4eed2c6c5092ed95b8ee6d994106c54a9fc6ed3e) >> >> I don't like this. I don't like these size info to be put on the titles >> of config options. A few reasons: >> * It can give a false impression that the size of the final busybox >> binary is the size of these applets summed up, but it's actually not. >> (Some code can share among applets) >> * The sizes are CPU architecture dependent. > > Sure, on a different arch, sizes would change, but "20k" applet is > still approximately 4 times larger than "5k" one. > that's useful information for the user. >
to be korrekt we would need to test with every new compiler/-option more over nobody knows when this claim was made. It should be clear for every programmer "your milage may vary" is here in big letters. >> * How the sizes are measured are even unclear. So, does the size include >> all optional features of the applet, or is it only the basic >> functionality? >> >> If I were to mention the size in menuconfig, I would put in the help >> texts of the config options, rather than their titles. And be clear how >> the size is measured, for example: >> >> CONFIG_BINZIP2 >> (Adds about 8.8kB on i686, for bzip2 decompression code) >> CONFIG_BZIP2 >> (Adds about 18kB on i686, for bzip2 compression and decompression code) > > Can you automate this for 400 applets and ~600 options? > I guess there is no need, what about a description in the beginig like "All sizes relate to i686, depending on your target arch this may differ" (replace i686 with anything you like) This would solve 2 problems. 1. it is clear what the base is (Kang-Che Sung point 3 is valid) 2. in future all claims like "save 200 Bytes (tested on MIPSxyz)" are off limits. re, wh >> Or alternatively, don't mention the size at all. > > The sizes are helping users see which applets are bigger. > Without sizes, it was pure guesswork: if someone optimizes for size, > he would semi-randomly choose what to "sacrifice". > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
