hello @user45643,

0. mostly solved.
1. I nearly overlooked your question reg. the 'not very clear' subject,
2. I had similar problems like you to find a way from theory and benchmarks to practical use,
   ( I want to use it for gnumeric as the 'go_dtoa' used there ( in the goffice library, adopted from Rich Felkers 'musl' ), has some shortcomings )
3. spotting that 'make' in the ryu/ryu subdir sets me free from hassles with bazel, after some time I checked that it's two distinct parts,
   a.) calculating the needed value,
   b.) producing appropriate output,
4. It's not too difficult a task to adapt the output. tried how far I can and think / hope success.
   I provide attached a tar archive ryu.tar.gz
   with:
   A. a patched 'generic128.c',
   B. a patched 'd2s.c',
   C. a little test program 'convert_long_double_to_string.c',
   D. a little test program 'convert_double_to_string.c',
   E. a build and use hint 'dm_build.txt',
   which manage to produce 'gnumeric style' output, '0' for '0', 'decimal' for [ 1E-4 .. 1E17 ) ( .. 1E21 for long ) e.g. the requested '0.3', and 'scientific' with min. two exp. digits for the rest of values,
   just set free in the ryu/ryu subdir, fire make and the test compilations acc. dm_build.txt,
   I tried to provide enough comments that changes for other format wishes are easy.
   feel free to check, use, spread but look to stick to Ulf Adams licensing.
   as my coding skills are limited I'd really really really appreciate any tests, review, feedback, comments, improvements!!!,
   IMHO Ulf has done a outstanding great job, and it deserves being spreaded.
   Test status here:
   I checked gnumerics 'shortest' output produced with go_dtoa and '"!" GNM_FORMAT_G' against the patched ryu in a sheet with 1 meg random values multiple times, the values match in every case, the strings are still different for some few values with questionable precision, e.g gnumeric says 79630192461941888 is a good and accurate decimal representation for a bin value, while ryu says 79630192461941890 is accurate enough as we get back the FP-value from less decimal digits, and I say pretending 17 digit accuracy in a range with at max 16 digits precision ( the ganularity of doubles is 16 here! ) is fake and thus 79630192461941890 is better, even that doesn't have a '10' accuracy but is needed for roundtripping, and I think 7.963019246194189E+16 would be best.

known shortcomings:

• above point which might be discussed,
• f2s not yet covered / touched as I don't need it, shouldn't be difficult, most in d2s was solved with a copy from generic128,
• urgently!!! seeking a performance optimized solution for 80-bit long doubles, generic is significantly slow, see issue #212.

Thanks! The code here isn't necessarily fit for direct consumption, and may need additional work to get the output you want. Note that libstdc++ uses the algorithm from here to generate the output you want (I think) from the to_chars method. If you can use that, that might be preferable.