Potentially rework build scripts/

rxrbln commented 2 years ago

AFAIR the current T2 build scripts/ are structured like they are since the ROCK Linux 2.0 rewrite about 20+ years ago, and were similar even before that. While I prefer not to change a running system and preserve compatibility, maybe two decades later it might be worth a rework to be more streamlined, modern and user friendly. Maybe refactoring this to one common frontend (instead of multiple scripts) with more modern argument parsing would be nice to have. Just to brainstorm: the top level script could be named t2 (or pkg ;-) with commands like:

./t2 build $pkg ./t2 download $pkg ./t2 build --target $target

if we simply name the top-level script "pkg", and "build" "install" to optionally use pre-build binary repositories that would allow stuff like: ./pkg install $pkg ./pkg remove $pkg # or uninstall?

although "./pkg build --target $target" might feel a little strange at first, compared to: ./t2 build --target $target

If we add some generic default location to the system PATH that would simply be:

pkg install something

This could potentially be combined with reworking the installed, see issue #60

N0T4G commented 2 years ago

Indeed a more modern and user-friendly frontend is long overdue for a rock solid distribution! I would lean towards a t2 top-level more than pkg.

lenticularis39 commented 2 years ago

Or perhaps keep the scripts and make pkg/t2 a frontend that in addition to emerging/updating packages also can manage the T2 source tree, e.g. mimicking apt-get:

pkg update -> svn up pkg upgrade -> scripts/Emerge-Pkg -system -missing=no

The scripts would stay as the low level part, while pkg would be a user friendly high level tool. I believe such a solution would keep the advantages of both hard refactoring and not refactoring at all (and hopefully bring more people to T2 by providing a familiar interface to manage packages in the system).

rxrbln commented 2 years ago

Certainly a huge fan of not breaking what works, not re-inventing the wheel and retaining historic compatibility.

We will certainly should work carefully and slowly on this, gradually improving the status quo. Maybe improving Emerge first, and certainly #60 is more important to takle first, or at least with higher priority.

lenticularis39 commented 2 years ago

We could do something like this (to make it intuitive for users of apt, pkgin or FreeBSD's or OpenSolaris' pkg):

pkg update - runs svn up in T2ROOT, default /usr/src/t2-trunk pkg upgrade - runs scripts/Emerge-Pkg -system $@ pkg install - runs scripts/Emerge-Pkg $@ (install updates dependencies on other systems too, we don't have to default to -missing=only) pkg remove - runs mine -r $@ pkg search - runs scripts/Find-Pkg

pkg being located in /usr/bin and shipped as a package/part of an existing package.

rxrbln commented 2 years ago

maybe our in source frontend scripts should be named t2 and the installed end user package maintenance frontend could be a symlink to pkg. Mostly to make it more "intuitive" for developers using t2 on other systems to build embedded Linux firmware not to confuse it with other "pkg" implementations, ...

paulwratt commented 2 years ago

This would qualify for a new Version Release (as opposed to Point Release or abn Update Release)

I too lean towards the use or t2 (as long as everything is also automatable from somewhere else - might be a good excersize for expect usage)

rxrbln commented 4 months ago

rxrbln commented 4 months ago

./t2 build|install|remove pkg --cfg mips64 --target build/

rxrbln / t2sde

Potentially rework build scripts/ #59