Creating user repositories is hard to test. Not sure if the concept
will survive the current workflow changes, disable it for now.
Signed-off-by: Jan Lindemann <jan@janware.com>
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).
Signed-off-by: Jan Lindemann <jan@janware.com>
If jw-build is already cloned, infect all other repositories with its
remote via PROJECTS_DIR_REMOTE_BASE.
Signed-off-by: Jan Lindemann <jan@janware.com>
JW_BUILD_SSH_EXTRA_OPTS contains a -l $(JANWARE_USER), which make ssh
break if $(JANWARE_USER) is empty. Fix that case.
Signed-off-by: Jan Lindemann <jan@janware.com>
The GIT_ASKPASS environment variable can point to a relative path,
and since pgit.sh currently does a chdir, it needs to be made an
absolute path.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Pass --branch $(JW_BUILD_BRANCH) to git clone invocations during the
initial cloning of jw-build. Used for testing.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Group variables related with pgit.sh (PGIT_SH and PGIT_SH_CLONE)
closer together. Define CLONE_FROM_USER early on.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Do not set JANWARE_USER to $(id -un) in case it's undefined. Instead,
rely on it being set explicitly in the environment if so desired.
Signed-off-by: Jan Lindemann <jan@janware.com>
Pass --create-remote-user-repos to pgit.sh clone in case JANWARE_USER
is defined, restoring the original behaviour.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Make list-files target ignore errors. This catches errors from
git ls-files | xargs realpath if git ls-files lists dead symbolic
links, as in my-project/blah/dev/fd -> ./proc/self/fd.
Implemented by passing -q (quiet) to realpath, not sure what else
this suppresses.
Signed-off-by: Jan Lindemann <jan@janware.com>
After initially cloning jw-build and including
projects-dir-minimal.mk, new targets are not considered, so run make
again.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Move nearly all of projects.py into src/python/jw/build/App.py. The
plan is to split the script into parts and import them.
Signed-off-by: Jan Lindemann <jan@janware.com>
The link to the projects dir toplevel Makefile is not created if a
jw-build directory already exists for some reason, fix that.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Re-add everything necessary for building and packaging jw-python.
ldlibpath.mk is not strictly necessary, but might be with other
Python packages backed by compiled C-code, so leave it in.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
Re-add all files necessary to package jw-build itself, i.e.
sucessfully run make pkg-rebuild-reinstall. This adds 1892 lines of
code.
Signed-off-by: Jan Lindemann <jan@janware.com>
This commit removes everything not strictly necessary for running
"make clean all" inside jw-build.
packaging jw-devtest. This cuts the repo down from 24077 to 4725
lines of code.
The idea is to
1) Further remove bloat from the remaining bits
2) Re-add what's necessary to build and package other essential repos.
The decision should be based on whether or not jw-build can also be
useful in a non-janware context.
Signed-off-by: Jan Lindemann <jan@janware.com>
The projects toplevel Makefile is not maintained in CVS anylonger but
in Git, so don't update it from CVS any longer.
Signed-off-by: Jan Lindemann <jan@janware.com>
"Makefile" is used in dependency checks within projects-dir.mk. Since
it might be included from projects-dir-minimal.mk, which also works
with "GNUmakefile", make this fallback of a predefinable variable,
PROJECTS_MAKEFILE_NAME.
Signed-off-by: Jan Lindemann <jan@janware.com>
Adapt projects makefile to match the mechanism all proj.mk's are
supposed to find their JWBDIR. Namely make JWBDIR_NAME a
conditionally assigned variable to allow for some testing of
alternative jw-build trees.
Signed-off-by: Jan Lindemann <jan@janware.com>
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.
Signed-off-by: Jan Lindemann <jan@janware.com>
htdocs.mk's install relies on source code having its HTML contents installed in
a subdir called "htdocs". Make that choice a variable named
"HTML_STOPDIR_NAME".
Signed-off-by: Jan Lindemann <jan@janware.com>
Support the Makefile variables PY_INSTALL, PY_INSTALL_REG, PY_INSTALL_PYC, all
defaulting to true. They can be set to false to stop installation of whatever
file type is undesired in the target. A common use case for this are
__init__.cpython-313.pyc, provided by a package the installing package depends
on. The prerequisite package might already provide these files for common
directories.
Signed-off-by: Jan Lindemann <jan@janware.com>
