Makefile: allow reinstall without uninstall, and rethink the per-component targets

Captured from a discussion between @pkgdemon and probono in #gershwin on 2026-08-25, 16:29–16:43 UTC.

## The problem

`make install` is a **silent no-op** on a system that already has Gershwin installed. `Makefile:9-15`:

```make
system: check_root
@if [ -d "/System/Applications" ]; then \
echo "Gershwin System Domain appears to be already installed."; \
else \
...install... \
fi
```

It prints a message and exits 0, so a re-run reports success and changes nothing.

The workflow that check pushes you toward — uninstall, then install — **cannot be completed on NextBSD.** `Makefile:44-47`:

```make
uninstall: check_root
@if [ -d "/usr/lib/system" ]; then \
echo "NextBSD system detected (/usr/lib/system exists)."; \
echo "Cannot uninstall /System on NextBSD as it may contain system libraries."; \
```

`/usr/lib/system` exists on every NextBSD system, so uninstall always bails. On the primary target platform there is currently **no supported way to reinstall at all**.

And the check is stricter than reality: installing over an existing install does work.

## The change

Remove the guard in `system:` so `make install` can be re-run over an existing install.

Clean reinstall stays the *recommended* path, it just stops being *enforced*:

> **probono:** for a clean reinstall the user should run uninstall, install
> **jmaloney:** exactly — but it's not strictly required

This also disposes of a `make update` target that came up and then resolved into "just remove the check":

> **jmaloney:** I also thought about make update […] to reinstall without make uninstall
> **probono:** how would that be different from make install?

## What it unlocks

The per-component targets already exist (`Makefile:20-42`) — `corelibs`, `workspace`, `systempreferences`, `eau-theme`, `terminal`, `textedit`, `windowmanager`, `components` — and CI already uses them to build one repo at a time. With the check gone they become useful interactively too: reinstall a single component instead of everything, and skip the manual sequence of `cd /Developer/Library/Sources`, sourcing `GNUstep.sh`, exporting `GNUSTEP_INSTALLATION_DOMAIN` and so on. `make workspace`, done.

probono noted he did not expect to need this himself, and was not against it.

## Open — target naming

probono's point was about not hardcoding the table:

> **probono:** wouldn't it be make gershwin-workspace because that is the name of the repo, so that you don't have to hardcode all of them?

Worth separating two things here. All eight rules are identical apart from one argument to `install-system-domain.sh`, so a component list plus a pattern rule removes the duplication **regardless** of what the targets are called. Renaming to match repos is the separate question.

- @pkgdemon liked the repo-name idea, with an aggregate `corelibs` kept as a deliberate exception, and thought an individual `make libs-base` could be useful too.
- Cost: renaming breaks CI, which calls these targets by name.
- Minor: the existing target is spelled `eau-theme` (`Makefile:29`), not `eua-theme`.

## Open — one-shot bootstrap

probono's ideal flow:

> git clone gershwin-developer
> cd .....
> make install dev
> something like that - it could run bootstrap, checkout,.... everything

Two snags, both raised at the time: `make install dev` is two targets rather than one, so it wants to be `make install-dev` or `make dev`; and the branch is currently a *checkout parameter* (`BRANCH=dev … checkout.sh`), not a make target, so such a target would also have to switch gershwin-developer's own branch. Probably its own ticket once the above lands.

## Also worth deciding

`uninstall:` is `rm -rf /System`, which is why it has to refuse on NextBSD — `/System` there holds real system libraries, not just Gershwin's. That guard is correct, but it leaves NextBSD with no uninstall story at all. Either that is acceptable and should be documented, or uninstall needs to remove only what it installed, which means tracking a manifest — a substantially bigger piece of work than this ticket.

Start in Makefile:9-15 and inspect the existing per-component rules at Makefile:20-42, along with the install-system-domain.sh invocation they pass. Remove the system install guard so reinstalling works, then verify that the existing component targets still invoke the intended repositories and that CI's target names remain compatible. Target naming and one-shot bootstrap are explicitly unresolved and should not be silently folded into this change.

Written by the indexing model from the issue text.