Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Mattias Andrée
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

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Eolien55
Страхиња Радић 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

Re: [dev] [sbase] Defining scope of sbase and ubase

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

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Mattias Andrée
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

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Randy Palamar
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

Re: [dev] [sbase] Defining scope of sbase and ubase

2024-03-08 Thread Elie Le Vaillant
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