Add an init target. Use it if you want to tell the Makefile: _Just_ initalize the build machinery and nothing else, don't pull and build everything else you can. Not strictly necessary, most of the time pulling everything is what's wanted, and that does the init anyway.
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.
Make jw-projects.py list-repos support a local directory as base URL of all git repositories, notably used by PROJECTS_DIR_REMOTE_BASE, which can now point to a local directory.
Targets defined by projects-dir.mk are not available before it is included, but make makes up its mind about what targets are available after parsing the included makefiles, so remove that redundancy.
On the other hand, a dependency alone is not enough for make to understand that an included makefile has been remade, it needs a rule, so add a dummy-rule body. In this case only echoing that the include file has been provided.
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.
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).
Currently, the primary discriminating criterion on how to handle a set of remote repositories is whether or not JANWARE_USER is defined. The canonical way to do that is PROJECTS_DIR_REMOTE_BASE, though, so go from that definition.
PROJECTS_DIR_REMOTE_USER_SUBPATH is a janware.com specialty somewhat. Having subpaths is a Forgejo feature request on Codeberg, though, so it might also be here to stay.
Pass -c http.proactiveAuth=basic to the initial "git clone jw-build" invocation. This is necessary while jw-build is still behind authentication. The restriction will likely be lifted (for jw-build), but for testing now it's fine, and it doesn't do any harm, either. With the way janware.com currently operates, it will also necessary for push over HTTP, so make it persistent in jw-build's configuration.
Linking the projects-dir Makefile fails if make pkg-rebuild has been run on jw-build, because it leaves another projects-dir-minimal.mk below the dist directory. Fix that.
The usage comments heading projects-dir-minimal.mk and projects-dir.mk state that for cloning all repositories, JANWARE_USER needs to be defined. That restriction is now gone, so reflect that in the comment.
Add the variable PROJECTS_DIR_REMOTE_BASE, defaulting to ssh://git.janware.com/srv/git if REMOTE_USER is defined, and to https://janware.com/code in case it isn't.
Re-add everything necessary for recursively building all repos in a directory, e.g. as a build controlled by janware.com/Makefile or any other installation.
This adds 489 lines of code which can (and should) be massively reduced, notably removing code supporting CVS.
In the attempt to move both jw-build and the janware toplevel Makefile from CVS to Git, add two new makefile snippets to make/*.mk:
- projects-dir-minimal.mk
A new toplevel-Makefile for building all projects in one go. It
should be suitable to be downloaded from janware.com/Makefile and
then be used to bootstrap all repos hosted on janware.com, that a
user has access to, just like the current toplevel Makefile is.
It is as small as possible: Little code means few assumptions on
what the world outside of it looks like, notably jw-build. This
is desirable, because it lives outside of version control, albeit
for a short while, and as long as it does, there's no mechanism
in place to keep it current.
That said, on first use, it replaces itself with a symbolic link
into jw-build and is then version controlled with jw-build.
- projects-dir-include.mk
This is essentially the existing projects-dir.mk /
toplevel-Makefile, which it includes. It's meant as a place for
adaptations to the next-generation implementation. This might
prove handy to have while both implementations coexist during the
transition phase.
