On Thu, Jul 20, 2017 at 8:22 PM, walter harms <[email protected]> wrote: > > > 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.
I can assume the size is measured with the default compiler options with a modern compiler -- nowadays building with GCC and building with Clang do not bring so much size differences, but it's still good if we leave a note about which compiler is used on measuring size. And I used the word "about" for the "your mileage may vary" meaning. >>> * 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. > What do you mean by "beginning" when it comes to menuconfig interface? And beside this, there're some more problem that I forgot to mention: 4. The sizes will definitely need to be updated somewhen to reflect the code changes, and I won't know how much maintenance burden will there be. Sure it can be automated (like size_single_applets.sh), but updating the Config.in files will probably make you crazy (sorry Denys Vlasenko). 5. What to do if someone propose a new applet into busybox? He or she couldn't have the same environment to measure the size. For my point no.4, how about this: Instead of putting the sizes in the Config.in files or source code, make them in an external text file named "size-ref.txt" (outside menuconfig). Then you can try any automate way to update the file, or even allow users to measure themselves, with their own environment. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
