"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.
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.
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.
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".
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.
$(GETTEXT_PROJECT_POT) is always generated if $(GETTEXT_INPUT_FILES) are newer than it. Having this happen automatically is not useful, since it can break manually edited and version controlled $(GETTEXT_PROJECT_POT).
It appears that inkscape, if invoked from the command line, fires up a splash screen if it has enough time to do so. This leads to strange flickering during the build process. Unset DISPLAY in the attempt to keep that from happening.
Currently, there's a $(GETTEXT_PROJECT_PO): $(GETTEXT_POT) rule, but since updates to the workflow now considers, allows and mandates one or multiple *.pot files as the authoritative source for translations, make this a pattern rule rather than only valid for $(GETTEXT_POT).
GETTEXT_INPUT_EXTS takes a whitespace separated list of extensions which are subsequently passed to find -name to locate source files which are meant to be run through xgettext.
The first argument to find, translateme, is not really meant to exist, it's just there to allow adding multiple extensions preceded by -o in a $(foreach) loop.
Try to make the workflow a little more versatile. As of this commit, .pot files are assumed to preexist, save $(GETTEXT_PROJECT_POT), which can be generated from source, and should be committed, too.
A directory with gettext.mk in it, provided it has a locale name, makes the parent directory to a working localedir, which can be used from within the janware source tree, so add it with the all target and remove it with clean.
jw-build is meant as a generic set of tools for building other projects, so references to projects being built by jw-build introduce a circular dependency. Remove those references from defs.mk and rules.mk.
Ubuntu 22.04 (and supposedly all Debian based distros) don't have a package called python anylonger, and use python3 instead. Using the unversioned [requires] sections for simplicity. Note that this might break backwards compatibility, and should be fixed as necessary.
The current globbing pattern for filling the PYTHON variable doesn't account for the fact that /usr/bin/python3.X might have more than one digit for X, fix that
