About the approximate applet sizes in menuconfig

[Kang-Che Sung]

On Thu, Jul 20, 2017 at 8:22 PM, walter harms <wharms at bfs.de> wrote:
>
>
> Am 20.07.2017 12:17, schrieb Denys Vlasenko:
>> On Wed, Jul 19, 2017 at 6:38 PM, Kang-Che Sung <explorer09 at gmail.com> 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.