On Sat, 09 Mar 2024 17:28:49 +0100 Elie Le Vaillant <eolie...@disroot.org> wrote:
> Страхиња Радић <cont...@strahinja.org> 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 There are also multiple standards, not just POSIX. For example tar, true, false are not POSIX (tar was removed from POSIX, and true and false are defined only as shell built-in in POSIX), but they are defined in LSB which a propular, but it's a Linux specific standard. Most of POSIX but not all of POSIX is also defined by LSB. > 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. sed -i is not POSIX. > > 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. I don't think there is any reason that sbase should implement all of the standard utilities you need, I think it should only be the small tools that you can reasonably write in one file. Large and complicated programs like sh should be it's own project. > > Regards, > Elie Le Vaillant >
