On 2024-03-13 11:27, Roberto E. Vargas Caballero wrote:
I am thinking about the new layout, and for now I was considering
something like:
- posix (tools defined by POSIX)
- misc (helpful tools not defined by POSIX).
- linux (tools that only make sense in linux)
- curses-terminfo (tools with dependency of terminfo, like clean and
reset).
- curses-dummy (curses tools implementation without using terminfo).
- libutil (library with utility functions)
- libsys (library with system dependant functions).
I think this layout has a few problems:
- we lose the meaningful separation that the sbase/ubase layout
allowed, i.e the distinction
between what is portable and what isn't. This _could_ be included as
part of the Makefile
(PORTABLE set vs NONPORTABLE), but I think it is better to
explicitly separate in different
directories portable from non-portable tools. If we don't, we are
making sbase a Linux-only
project (the only implementation for ps becomes a Linux-only one,
and we would need to fork
sbase to make it available to other platforms; same for all the
other tools from ubase), which
I find a bit sad considering the goals of portability of sbase
- I think Mattias Andrée scheme is better than this one. With a
directory-base separation
(between categories of utilities, based on somewhat arbitrary
factors (standards, rather than
say, minimalness, or use-case, or platform or implementation,
etc.)), we cannot have overlapping
categories, which is quite problematic. For example, if we wished to
have a category for
"shell-only usage" (such as clear, or cols), we couldn't implement
it in an easy way, because
this category overlaps with misc/, curses-dummy/, and maybe others
too.
What I suggest to fix both problems:
- separate on the grounds of portability/nonportability. In other
words, something along the lines
of:
libutil/
portable/
ls.c
cols.c
unportable/
linux/
lsmod.c
ps.c
libsys/
maybe-other-os-in-the-future/
This more or less reproduces the sbase/ubase separation, but
allowing future OSes to come in
the future rather than just Linux (so, for example, *maybe* OpenBSD
could have some tools in
the future. This is a suggestion).
- Allow for categories _inside the Makefile_. We could have something
like:
POSIXTOOLS = portable/ls unportable/$(OS)/ps.c ...
MISCTOOLS = portable/sponge.c portable/cols.c portable/rev.c ...
INTERACTIVETOOLS = portable/cols.c portable/clear.c ...
...
BIN = $(POSIXTOOLS) $(MISCTOOLS) $(LINUXTOOLS)
This allows for such grouping, while also allowing overlapping
categories. This also doesn't
hinder the useful semantic sbase/ubase separation (which is
especially handy when working on
non-Linux OSes). I think overall that sbase/ubase is the most useful
distinction, so it should
be treated specially, and not as part of the build-system (but more
as part of the directory
organization).
Possible drawbacks which I've thought about could be:
- This requires to occasionally write and update different,
overlapping lists of tools. I believe
this is not too much of an issue. Adding new items should be quite
easy, and you've already done
a form a grouping which we could use for this proposed alternative
layout. This task could also
be aided by the way busybox groups its different utilities, and the
different standards and
packages listed on the toybox website.
- The Makefile would be a bit more complex. If we truly add support
for multiple platforms (which
is a mere suggestion), it could become a bit complex (as in:
platform-specific bits of Makefile
to properly compile libsys, or platform-specific utilities (lsmod,
sysctl...)). If we don't,
and just keep a portable/linux separation at the directory-level, we
still need a bit more
complexity (defining tool categories, properly distinguishing
between libutil and libsys at
compile-time, and only for platform-specific tools, etc.) than what
we currently have, but this
complexity would be very similar to the one we would have with your
proposed layout.
Overall, I think that the benefits of the proposed alternative layout
(sbase/ubase primary distinction,
reflected at the directory level; and Makefile-specific lists as
secondary distinction, only reflected
at the build-system level, which allows very great flexibility) outweigh
the inconveniences. Moreover,
I think that your layout has issues, such as the fact that sbase becomes
a de-facto Linux-only project,
considering that tools whose implementation are Linux-specific (ps,
mknod, etc.) are not treated
differently from tools which are inherently portable (sponge, sed...),
or the fact that the categories
you've made so far forbid 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
