For a project to supply templates, it needs to advertise their location. For this, the tmpl_dir make variable is added to projects.mk. If other-project wants to get hold of some-project's templates, it can do, e.g.:
Templates (i.e. text files ending as .tmpl) are not part of jw-pkg anylonger, but controlling the way they are installed is beneficial to other packages, so add tmpl.mk back.
That said, the variable names will need some tweaking to avoid collisions. Postponed.
To avoid name collisions, rename svg.mk to the more specialized svg-to-pixmap.mk, because that's what it does. To the same end, rename $(SVG) to $(PIXMAP_TO_SVG_SRC_SVG).
--create-remote-user-repos had been disabled in 4053451bfd on the grounds that it's hard to test and possibly superflous. It actually is not superfluous, as devops builds show, and that's a valid test-case, so re-enable it.
Running "make install" from an arbitrary source directory currently by default either installs to a user-accessible ENV_PREFIX, or, if DEVELOPMENT is set to false, tries to install into the system's root filesystem, but fails over permission errors. This was by design: To now, I considered trying the latter ill-conceived, because installing without package manager control bears the risk of leaving unversioned files in the system.
Actually, thinking again, during development this looks like a valid use case: Having run pkg-rebuild-reinstall before, installing from a source directory will leave a trace in the package manager's hash check output, will be handled during the next clean install, and might be a useful shortcut for trying things in the root file system.
JS_MINIFY_FILTER_IN can be defined to nothing, in which case minifying breaks, so don't minify if there's no filter. As an additional benifit, defining it to the empty string in local.mk allows to use Vim's quickfix window for syntax errors, because there's no intermediate file created.
tailwind.mk is meant to generate a CSS file with tailwind classes from configuration files named *.css.tw or *.css.tw.tmpl. The latter flavour understands some make-style variables, as of now only $(TOPDIR).
Define DATA_DIR, the directory where read-only, non-executable and non-configurable resources should be stored. And define JSON_DIR as $(DATA_DIR)/json.
PACKAGE_VCS_FILES defaults to false. Defining it to true before including rpmdist.mk includes the version-control metadata files in the source packages.
"git fetch $remote $fromref:$toref" fails if the $fromref is behind $toref.
Unrolling the syntax into "git fetch" followed by "git merge --ff-only $remote/$fromref $toref" is accepted, though, and saves some otherwise necessary case distinction code around it.
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.
--login is not understood by pgit.sh push. Solve that by allowing all commands a --login option. This addresses our use case, but isn't ideal of course. Will be finally fixed by moving pgit.sh's functionality into Python code.
pgit.sh clone --login <username> fails to insert said username into a remotes url while adding it: Of ssh://<username>@git.janware.com/srv/git, only ssh://@git.janware.com/srv/git makes it into the config. Fix that.
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.
In the attempt to move away from communicating options via environment variables from one part of jw-build software to another, replace PGIT_CLONE_FROM_USER with the clearer --refspec option. Which is also more versatile.
Don't unconditionally add proactiveAuth=basic to Git's config during clone, but only if cloning happens after authentication.
This saves unauthenticated users funny password prompts. On the other hand, this makes a server setting persistent which could be changed on the server.
URL =~ /api/ (or so) => 401, followed by Basic Auth URL !=~ /api/ (or so) => Redirect or free access, depending on resource
Currently all resources, including API, are accessible by either basic auth or a Cookie, but basic auth needs to be present in the first request, which throws off some clients (notably Git without proactiveAuth=basic).
