Страхиња Радић <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 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
