Add get-pub for top directory / projects directory level. This is a janware specific target needed for CI. It integrates the current master branch from the new Forgejo-based Git repos.
That said, this will likely need to go along with other release machinery. Packaging is good, but releasing over a bunch of directories is an intricate process, as-is only usable by janware itself, and doesn't need to be part of jw-pkg.
With the exception of the "info" subcommand, nearly all of distro's subcommands deal with package managing, so push them into their own command category.
CmdCanonicalizeRemotes / canonicalize-remotes and the respective target in topdir.mk remove the /srv/git portion from all remotes' URLs pointing to git.janware.com.
jw-pkg supports more than RPM-based package managers, but for historic reasons, lots of its Makefile variables still have "RPM" in their names. This is misleading. Replace "RPM" in variable names by the more generic "PKG" where appropriate.
Use pkg-requires --hide-self to find all prerequisites that should be installed for a test run against packages installed from the repositories, including self-built and self-hosted packages.
In a push to eventually merge the classes, somewhat align the command-line API of CmdRequiredOsPkg to the one of BaseCmdPkgRelations by using dependency flavours as mandatory, first argument.
Move the dependencies listed in BASE_PKGS from projcts-dir.mk and topdir.mk into project.conf.
Due to various hen-and-egg problems on a minimal system, in some situations these packages can't be installed from project.conf. The same is true with BASE_PKGS, however, so remove it, at least that does away with some redundancy.
Make pkg-install-testbuild-deps an alias for pkg-install-release-deps. At this point, they do nearly the same thing, and the distinction between what the implementations should do are blurry at best. This commit removes redundancy but keeps the use cases distinct. Different implementations can be reinstantiated should requirements for different implementations become clearer later on.
The code below lib.distro, as left behind by the previous commit, is geared towards being directly used as a command-line API. This commit introduces the abstract base class Distro, a proxy for distribution-specific interactions. The proxy abstracts distro specifics into an API with proper method prototypes, not argparse.Namespace contents, and can thus be more easily driven by arbitrary code.
The Distro class is initialized with a member variable of type ExecContext, another new class introduced by this commit. It is designed to abstract the communication channel to the distribution instance. Currently only one specialization exists, Local, which interacts with the distribution and root file system it is running in, but is planned to be subclassed to support interaction via SSH, serial, chroot, or chains thereof.
Currently git-get-% pulls into the master branch. Change that to pull into the branch currently checked out in the workspace, because that's the more likely use case if you want a quick update from somewhere.
"clone" in the Git sense means to copy a remote project over from scratch. pgit.sh clone has come from that, but has since evolved into something different, a mixture of clone, pull and fetch, so find a different name. "get" seems generic enough and doesn't clash with a Git meaning. Adapt variable names accordingly across the project.
git-pull-<username> doesn't use pgit.sh if username == login. pgit.sh should handle that case fine now, so remove the distinction from topdir.mk and make it in one place, i.e. pgit.sh. This has the additional advantage that pull as done by pgit.sh conveniently uses --autostash.
Use pgit.sh to for the git-pull-% target. This should make git-pull-maintainer work. To limit the blast radius for now, only use it if the source user differs from the invoking user.
--quote puts double quotation marks around the listed dependencies, protecting version requirements (>= 1.0) and parenthesis "perl(GD)" from the shell.
Retire pkg-manager.sh and replace it by the cleaner "jw-pkg.sh distro" command, essentially providing the same functionality and nearly the same command-line interface.
400 LOC more. That's what the move from a shell script to the more maintainable Python versions costs. Still a good idea, and the enhanced extensibility might pay off in terms of LOC with other shell scripts in the future.
Reorganize the Python module structure. Placing the command classes under jw.cmds.projects instead of jw.build.cmds will allow to add a nested command structure, with the current commands, being mostly related to building software, found below a "projects" toplevel command.
Other conceivable commands could be "package" for packaging, or "distro" for commands wrapping the distribution's package manager.
This commit aims at improving speed by using better caching.
- Makefile, cache.mk: Split .cache.mk up
To allow caching of runtime path variables which are
project-specific, split .cache.mk up in .cache-project.mk and
.cache-projects.mk
- ldlibpath.mk: Cache ldlibpath, exepath and pythonpath
Place the output of $(call proj_query ldlibpath), $(call
proj_query, exepath) and $(call proj_query pythonpath) in
JW_PKG_LD_LIBRARY_PATH, JW_PKG_EXE_PATH, and JW_PKG_PYTHON_PATH
respectively, and cache the variables in make/.project-cache.mk.
- cache.mk: Use = instead of :=
Recursively expanded variables are nearly as fast as := variables
if the assigned value is a fixed string. And sometimes it's not,
rightly so, because variables get assigned below, as with
JW_PKG_XXX for instance.
- cache.mk: Use $(TOPDIR) as variable values
Replace absolute references to project's topdir by $(TOPDIR) with
sed. As soon as the project queries produce absolute paths, they
will be transformed into relative paths which allow the code base
to be moved to a different location and still remain functional
without a rebuild.
There's little system in the pkg-install-xxx targets, add one more to increase the confusion. It's needed to install all packages needed to do a standalone build against the packages installed into the system via package manager. That said, the respective jw-projects.sh commands need broader refactoring, as well as the pkg-install-xxx target naming.
jw-build doesn't stop at building software, packaging it afterwards is also a core feature, so this commit gives the package a better name.
The commit replaces strings s/jw-build/jw-pkg/ in text files and file names. Fallout to the functionality is fixed, variable names are left as they are, though. To be adjusted by later commits.
git-pull-% pulls whatever $(GIT_MAIN_BRANCH) happens to be from the remote jw-% into the current branch, with --rebase and --autostash.
git-pull-maintainer does the same with <maintainer>. <maintainer> is figured out from the configuration in projects.conf. If it's the invoking user, origin is used.
Identify the remote's name by $(PROJECT) instead of $(RPM_PROJECT) now. Don't know the exact rationale for $(RPM_PROJECT), but in case of arm-none-eabi-mcu-blink it was certainly wrong.
