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

Reply via email to