$(TOPDIR)/scripts contains a symbolic link jw -> ../src/python/jw, to allow jw-python.py access to the in-repo module jw.pkg. Should be fine now even on Windows, OTOH, it's also solvable via __init__.py, so do that.
To support minimal environments, notably minimal Docker containers which don't have /usr/bin/sudo by the time pkg-manager.sh is invoked (possibly to install sudo), support running all commands without invoking sudo first. Of course this only works if invoked as root.
Note that this is still somewhat hacky, command-line parsing needs to be cleaned up.
"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.
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).
Replace git-srv-admin.sh list-personal-projects by the more universal "jw-projects.py list-repos" for enumerating repo names. This is a step towards supporting Git servers other than janware.com.
Add support for --create-user-repos to pgit.sh. It controls whether or not personal remote repositories on janware.com are created when cloning from another user.
jw-pkg is related to, but strictly speaking not indispensible for building and packaging software. So, in the attempt have a minimal jw-build, move jw-pkg to jw-base, and fix all packages that use it.
There's a certain logic that jw-pkg is part of jw-build, because it comes in handy to compile config file templates in a post-install stage. On the other hand, jw-base looks like a better place for that.
Re-adding for now, to not break too many packages.
Implement the functionality of create-pkg-config.sh in a Python module CmdCreatePkgConfig.py. This allows to remove create-pkg-config.sh and jw-build-functions.sh.
Note that the translation was done pretty literally to play it safe. More code can and should be removed by taking advantage of the fact that jw-projects.py knows more about the project than the shell scripts.
Re-add everthing needed for building and packaging ytools. This is a big commit, 2002 lines of code. It mostly consists of C/C++ machinery, plus some documentation-related stuff.
jw-pkg determines the file attributes of template compilation output via a line matching the '^#\s*conf' regular expression. Allow that regex to be configured.
proj_dir() raises an exception for projects which don't have a dedicated project directory, even though for some projects this is legal. php-cli, for instance, only installs stuff below /srv/www/proj/php-cli.
