On Sunday, March 24th, 2024 at 04:09, Rob Landley <r...@landley.net> wrote: > On 3/24/24 01:00, Oliver Webb wrote:
> This isn't the hard part. To me, the hard part is wanting to share lib/.c code > with this new binary, which implies it would live in toys/example/.c, which > means in the NEW design it would be a normal command that's "default n"... and > maybe depends on TOYBOX_BUILD or some such? Except moving stuff from > scripts/.c > to toys/.c is conceptually ugly. But if we're getting rid of the > subdirectories... Maybe make.sh needs to be able to build commands that DON'T > live in toys/ but then... There is a chicken and egg problem with the build infrastructure and kconfig being a toy, We need a .config file to build toys, and parsing the help text requires some kconfig parser, But we can't make a .config file until we have kconfig. The solution I thought of was to use the infrastructure that we will have to have to remove bash and gsed dependencies to build kconfig as a early step in the process. But then we will still need to extract the help text. Which implies we'd have to keep config2help.c, we'd have 2 seperate kconfig parsers, so maybe the solution is to build more upon config2help.c, we could "#include toys.h" (Although that includes generated/config.h, so "#ifndef TOYBOX_BUILD" and -D it in the CFLAGS for building this) and build with lib/*, Then again... Do you plan on not keeping 2 different kconfig parsers or moving scripts/*.c to toys/example (We could make toys/build tho, which would make slightly more sense), There's circular dependency nightmares that would HAVE to be worked around at one point or another, a lot of stuff in the infrastructure relies on kconfig so making kconfig rely on the infrastructure would require bootstrapping it in a weird way, but there are also problems with that (main.c includes generated/*help.h files, toys.h includes generated/config.h), So if the actual solution is to not make it a toy and build it with lib/* and toys.h to codeshare with lib/, that creates problems too... Does any of lib/ depend on those functions in toys.h that live in main, grepping through, of course there are parts, which means more ifdefs if we wanna pry it off the infrastructure, sigh. - Oliver Webb <aquahobby...@proton.me> _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net