Hi,
After reading the opinion of the people in this thread,
I think the best option is to merge the sbase and ubase
repositories and having a mechanism in the build system
to select the set of tools to be included in the build.
The main drawback of this is that the build system will
be more
> Everything in the quoted part seems personal preference.
I've been managing my vim plugins with git submodules via vim's builtin
"packadd" directory structure (~/.config/vim/pack/plugins/start/...).
And I can tell you that trying to do anything remotely non-trivial with
them is simply not a
On Sat, 09 Mar 2024 17:28:49 +0100
Elie Le Vaillant wrote:
> Страхиња Радић 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
On 24/03/09 05:28PM, Elie Le Vaillant wrote:
> Or is it out-of-scope for us to implement a full-blown shell? I really am
> not sure.
I think it would be interesting to have "official" suckless versions of all of
the mentioned programs, which would at minimum implement their descriptions
from
Страхиња Радић 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
On Sat, 9 Mar 2024 14:53:07 +0100
Страхиња Радић wrote:
> On 24/03/09 12:59AM, Mattias Andrée wrote:
> > I agree, a single repo (or alternatively making libutil it's own repo) is
> > necessary if we want one binary, and I think we do.
>
> Compiling all programs into one binary is currently an
On 24/03/09 12:59AM, Mattias Andrée wrote:
> I agree, a single repo (or alternatively making libutil it's own repo) is
> necessary if we want one binary, and I think we do.
Compiling all programs into one binary is currently an option, and IMHO it
should remain an option. In my own toy distro[1]
On Sat, 09 Mar 2024 12:10:28 +0100
Eolien55 wrote:
> Mattias Andrée wrote:
> > I think there should be one directory called "portable" containing only
> > tools
> > from sbase, and one directory called "linux" containing the tools from ubase
> > and maybe even symlinks to the tools in
Mattias Andrée wrote:
> I think there should be one directory called "portable" containing only tools
> from sbase, and one directory called "linux" containing the tools from ubase
> and maybe even symlinks to the tools in "portable". This structure would allow
> us to add implementations for
On Fri, 08 Mar 2024 23:33:12 +0100
Eolien55 wrote:
> Страхиња Радић wrote:
> > The problem of having separate *box executables could be solved by creating
> > an
> > "umbrella" *box project, perhaps having sbase, ubase and
> > [insert_letter]base as
> > git submodules, and deciding what to
Страхиња Радић wrote:
> The problem of having separate *box executables could be solved by creating
> an
> "umbrella" *box project, perhaps having sbase, ubase and [insert_letter]base
> as
> git submodules, and deciding what to build based on the contents of config.mk.
The problem is that
On 24/03/08 06:40AM, Roberto E. Vargas Caballero wrote:
> I would like to move the discussion here and see what alternatives
> we have and how to proceed in this case.
IMHO, if the intention behind sbase was to provide a minimal portable POSIX
utilities implementation, anything not fitting that
I think we should keep the implementation of each tool as minimal as
possible, but POSIX-complete, and of course common tools such as
install(1) and tar(1). However, actually using a system that is
nothing more than POSIX is very cumbersome. And I think it is a better
solution to implement
Elie Le Vaillant wrote:
> Another idea could be to have both in the same git repository,
> [...]
This would be my idea as well. It also wouldn't be that difficult
to let people pick and choose which sets of tools to include in the
final -box via config.mk or similar. I would stick with only the
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
Hi,
While reviewing several patches for sbase adding new tools
some discussion happened and I thought it was better to move the
discussion here.
The patches raised a concern about what should be the scope of
sbase. The idea of sbase was to provide a minimal portable POSIX
base, while having
16 matches
Mail list logo
