Work on pure cross-compiling

[takusuman]

And per the entire dslm4515/CMLFS#91 issue, I think it's a great time to start doing some more research --- or rechérche, if you're eating some baguette and drinking café --- on cross-compiling Copacabana directly from a toolchain to a working system, without depending on chroot/Mitzune, Docker, QEmu or any other mean, like good ol' UNIX's been doing since at least the 70's. I hope this could render a new compilação.md with new instructions for building Copacabana directly into a working system.
About references, since we do alchemy standing on giants' shoulders, here are some:

• As per [Sugestion] Statically Linked Binaries pacote#9 (previously "motoko"):

Me: My real preoccupation for now is making the system itself. I already did once, but it was with GCC and the process was manual enough to produce an enormous "paper" about cross-compiling Linux, and I wish I could make this more automatic [...]
xplshn: Have you checked out Sabotage Linux's build and bootstrap scripts? They are a good resource, and their build scripts for some packages too [...]

• https://github.com/oasislinux/oasis
  https://github.com/oasislinux/oasis/blob/master/.build.yml

• https://github.com/eerimoq/monolinux

• https://github.com/landley/toybox/tree/master/mkroot

• https://github.com/PhysixProject/physix

• Maybe take a look at how SunOS and Plan 9 build systems work(ed), so we can refactor and simplify build-system, since it has become a little bit too complex and may prejudice maintainability in the next months or years. Not to copy it, but learn something from.

The goal is to also collaborate on Clang Musl LFS back, as we've been doing since 2021.

[takusuman]

Of course, how can we forget: https://github.com/landley/toybox/tree/master/mkroot

[takusuman]

Oh, well, I didn't.
Anyway, studying mkroot today.

[xplshn]

Hi, good evening. Have you thought about using a structure like the following for building the base system? It is the Unix way:

Both the utilities and kernel are placed in the same directory. A top-level mkfile, or Makefile, is placed here. This mkfile checks for the availability of a C compiler and some other .a libraries, etc. After the sanity checks are done, variables are set, and engines are prepared, it enters bin, where the Heirloom-ng utilities are built. After building each one, it returns to the previous directory and proceeds to build usr.bin, where utilities such as the package manager(s) will be placed. After this, the last step is to build the etc directory (yes, we should build the etc directory; by "build," I mean using placeholders that are replaced with sed to update copyright dates in each cfg file, etc.). Once these and some other directories are built, the build system will enter the kernel step, placed under linux/. You surely get the gist of it already...

[takusuman]

Hi, good evening.

Hello, good afternoon.

Have you thought about using a structure like the following for building the base system? It is the Unix way:

Both the utilities and kernel are placed in the same directory. A top-level mkfile, or Makefile, is placed here. This mkfile checks for the availability of a C compiler and some other .a libraries, etc.

Yes, I have mentioned SunOS 4.1.4's build system in the first comment, but there's a couple of reasons about why we can't do it in the Linux world with outsourced packages. The biggest reason is because of versioning: it doesn't make sense to copy the code from Heirloom NG every time a release comes out, even if it's done by us, when we can just change a couple of numbers on the sources.txt. The same goes for L.E.mount, the pacote package manager, and, of course, the kernel. It would also fill the repository with code that we already have in others.
The situation on Copacabana, T/2, damn, any Linux distributions differs radically from Solaris, for instance, because we're not another vendor creating a fork of a "static" source code --- like Sun Microsystems was for Solaris, IBM for AIX, etc did with AT&T's UNIX ---, instead we're building a system using mostly outsourced software.
The sanity checks that would be made by a makefile are already being done by checks/dependencies, and the "tasks" itself are called by the function _make.
I know it looks clumsy because of, well, shell itself, but considering that the majority of distributions nowadays are built on "clumsier" pieces of code, I think this is the best we can come out for the present world. But, since everything can get better and this is a fairly democratic project, I'm open to suggestions of how code here can be rewritten for the better, which parts of the build system we can refactor and template suggestions for package/set build scripts.

[takusuman]

I'm currently thinking of abolishing the "alambiko" repository and moving package/set scripts for this repository.

[xplshn]

I get it, getting a build env chroot/rootfs or an initial image release would be best to attract people to the project. I know I'm not the only one craving Unix & gaming. (I'd be using 9front for everything if I could, or even SysV + the RC shell from Unix RS. R. 10, + kenCC compiler, etc)

[xplshn]

I'm currently thinking of abolishing the "alambiko" repository and moving package/set scripts for this repository.

Think it'd be for the best to unify the package manager and system repo, since most distros can be bootstraped from another one just by using their package manager, for example, you can use apk to create a bootable Alpine Linux install on a mounted drive, from within Void, Devuan, etc.

Nowadays, the package manager is itself the system, since it contains the entirety of the system's files in its repos (or at least, it should).

[xplshn]

Another distro that I think should be "studied" or could be used as inspiration is Carbs Linux, a Linux-based OS with no fat; https://carbslinux.org ; https://github.com/CarbsLinux/repository ; https://github.com/CarbsLinux

EDIT: Unrelated, but you need a telegram group/some sort of chatroom to discuss this kind of thing