Re: [dev] [sbase] New branch for sbase+ubase
ciding the categories then it should be the next step. Of course! I think some tools could be hard to implement in a portable way though... sysctl and mount being the worse offenders I can think of. The main reason I think we should have only one grouping is because it makes very simple the Makefile. The default configuration should include only posix/, and if you want to add more things then you can select the correct categories to be included. If you want linux tools, then add them. This removes any autoconfiguration. Well, I think you can have that with Makefile variables. So: POSIX = basename\ cal\ cat\ chgrp\ chmod\ ... xargs\ yes UNIX = cron\ dmesg\ getty\ ... which\ whoami MISC = ... CURSES = ... LINUX = ... BIN = $(POSIX) # by default. # Can be changed to: # BIN = $(POSIX) $(LINUX) $(UNIX) # or something along these lines I believe this also makes the Makefile very simple (at least, not much more than what it is already), and moreover easily allows a sbase-box recipe. Without some mechanism like that, I'm not sure how you could implement it. Maybe by having each Makefile have a PHONY recipe like "list-utils" and use it in mkbox? I'm really not sure if this is better than just a single, simple root Makefile. The issue is different for libutil/, libutf/, and libsys/ as sbase-box only needs the .a file, and as it cannot be "configured", and a library-level Makefile would probably be better than a root-level one. Of course, the complex part would be in libsys, that has to autodetect the system to compile the specific code for the host system. Couldn't we use a SYSTEM or OS variable instead? Kind regards, Elie Le Vaillant
Re: [dev] [sbase] New branch for sbase+ubase
d any kind of overlapping; in particular, it makes somewhat arbitrary categories such as posix/misc/curses... mandatory, and disallows us to have multiple types of categories defined along different axis (standards, use-case, platform where it makes sense (like linux for example)...). Thank you for your time and your efforts, Regards, Elie Le Vaillant
Re: [dev] [sbase] Defining scope of sbase and ubase
Страхиња Радић wrote: > Compiling all programs into one binary is currently an option, and IMHO it > should remain an option. I fully agree. However, the single binary situation should be improved. > Great, combine the two versions of libutil into a single, separate > libutil repository I'm not sure whether or not this is a good idea, because it makes sbase and ubase dependant upon a separate repository, which needs to be present in the parent directory for it to build. It'd also make sbase development cumbersome, because we very frequently change libutil when we change sbase. Both are developed as one single project, and patches reflect this. libutil should not be isolated I think. > then have a directory hierarchy like this: > > corebox > ├──sbase (portable only) \ > ├──ubase (nonportable) depend on libutil.so and/or libutil.a > ├──xbase (non-POSIX) / > └──libutil (option to produce .so and/or .a) ubase is not only nonportable, it is _linux-specific_. It is also non-POSIX. I think ubase should be renamed to reflect this. The distinction between POSIX/non-POSIX is, I think, not very useful. As Mattias said, pure POSIX is quite cumbersome, and not very descriptive as of what you can expect from it. sh and vi are POSIX, but out-of-scope for sbase (from the TODO), whereas sponge is crucial for sbase (it allows simpler implementation of -i for sed, which _is_ POSIX, or the -o flag for sort (POSIX too)) and would thus be excluded from sbase and put into xbase. The solution Mattias proposed (having one big repository, a portable subdir, a linux (and maybe others in the future, like openbsd) subdir and a Makefile which includes more descriptive sets than POSIX/non-POSIX (well, it _can_ be used, but it is not enough)) is I think the best to fix the problem of libutil duplication/drifting away of versions. It also allows a broader scope without impeding on the goals of sucklessness. One supplementary question, more in line with the original question asked by Roberto E. Vargas Caballero, is: would awk and sh be out-of-scope? Should we rather try to implement extensions to awk, or follow the specification as strictly possible? Should we implement POSIX sh, or some other shell, such as rc? Or is it out-of-scope for us to implement a full-blown shell? I really am not sure. Regards, Elie Le Vaillant
Re: [dev] [sbase] Defining scope of sbase and ubase
Hi, I think one of the main current issues with the current organization of sbase's and ubase's code, is that while they share parts of code (some parts of libutil are shared), they do not actually have it in common. As a result, changes to shared parts of libutil in sbase are not reflected in ubase, and vice-versa. Some parts of ubase's libutil are not portable, so indeed it makes sense that they are ubase-specific. But some, such as recurse, strtonum, strl*, ealloc, eprinf, and maybe others, serve the same exact function as in sbase, but sometimes vary in implementation, because they didn't receive the same patches. So I wonder: - Is this a problem that needs fixing? (I think yes) - How do we fix it? We could sync both periodically, applying whichever patch change both *base's libutil to both. Another idea could be to have both in the same git repository, allowing libutil (and possibily more code, like libutf if we ever need to) to be shared between them both without syncing them back and forth. My idea would be something like this: sbase/ portable/ ls.c cols.c ... unportable/ ps.c kill.c ... libutf libutil/ portable unportable Makefile This could fix the "multiple -box" problems. This would require rewriting some parts of the Makefile (for example, having PORTABLEBIN and UNPORTABLEBIN to select whether or not we want the unportable utilities; the mkbox script also), and could also provide a solution for the "moretools" repo by having it being a separate directory in this hypothetical repository. Also I'm not sure whether we should keep the goal of being POSIX-compliant. ls doesn't columnate, we have (non-standard) cols to do this. sed doesn't have the -i flag, we have sponge for this. cron isn't specified by POSIX, only crontab is. Maybe toybox roadmap's section on POSIX is relevant: https://landley.net/toybox/roadmap.html I think we should try and implement a minimal Unix-like userspace, and allow ourselves some freedom on what to implement. We already do this with sponge and cols. On ubase it is true also, with ctrlaltdel for example. I do not see why not do it more. Overall I think bringing everything in the same repository, with what is now sbase and ubase in separate directories rather than separate repositories, would fix both the current situation, and allow for a "sextra"/"uextra" directory for supplementary tools. Mattias Andrée already proposed this back when he proposed a patch for shuf(1): > No, we don't really need shuf(1) in sbase, but I think we > should have a suckless implementation available, it can be > a useful utility. I have a few more utilities I fund useful > but I haven't bothered to set up a repository yet. [...] > I think it might be a good idea to have sextra for portable > utilities and uextra for unportable utilities, if you have > any other suggestions I would like to hear them. I think this could fix the current situation, with code on different versions split between 2 repositories and ultimately 2 -box binaries, and allow a broader scope without impeding the goals of minimalness of sbase/ubase. Regards, Elie Le Vaillant
