On Sat, 9 Mar 2024 14:53:07 +0100
Страхиња Радић <cont...@strahinja.org> 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 option, and IMHO it
> should remain an option. In my own toy distro[1] based on Musl-LFS and using
> sbase and ubase I compile all programs from {s,u}base separately.
>
> The reasons why I consider that beneficial over a single executable include,
> but are not limited to:
>
> - Easier to maintain: if an administrator decides a utility is unnecessary or
> shouldn't be available, it comes down to rm-ing the file vs recompilation
> of
> the entire *box.
>
> - More robust: in case of disk corruption, all of the utilities are
> unavailable
> vs only those affected.
>
> - Fine-grained control: separate programs can be compiled using specific
> compilation options (eg. -g -O0) vs all of the programs sharing compilation
> options.
>
> etc.
>
>
> > Even if submodules was possible, I do not think they are a good solution.
>
> What makes the git submodules not possible?
I haven't actually checked, but it safe to assume that if it is not
already a problem it very well could become one (and it probably is).
If the two libutil implementations have functions with the same names
they cannot both be linked into the same binary. A "solution" would
be to use weak linkage, but then you can run into problems when the
functions that share name do not share behaviour (e.g. have different
prototype or return type).
>
>
> > Using submodules is unpleasant and pointless since all could is under our
> > control. I think submodules should only be used for code that you do not
> > have control over but need the source code for. Either you have separate
> > repos and have normal compile time dependencies (require that the libraries
> > are installed) or you put everything in one place, one repo.
>
> Everything in the quoted part seems personal preference. Git submodules offer
> a
> way to easily establish a hierarchy of git repositories while keeping them as
> separate "units".
Of course these are personal preferences. There aren't any technical problems
using git submodules assuming you can put everything in the same repo.
>
> So the libutil differs in sbase and ubase. Great, combine the two versions of
> libutil into a single, separate libutil repository, 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)
>
>
>
> [1]: https://strahinja.srht.site/galeb
>
