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?
> 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".
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
