R CMD check auf dem Mac: Forschungs-Paketabnahme 2026

Vor dem Check eine reproduzierbare Ausgangslage festhalten

Ein Ergebnis ist nur dann für die nächste Person brauchbar, wenn sich rekonstruieren lässt, womit es erzeugt wurde. Notieren Sie vor der Prüfung den Commit oder Quellstand, die R-Version, die aktive Architektur, die macOS-Version sowie direkte und für den Build benötigte Abhängigkeiten. Das ist keine Formalität: Ändert sich später ein Compiler, ein Systempaket oder der Paketstand, kann derselbe Fehler eine andere Ursache haben.

Legen Sie dafür eine kurze Umgebungsnotiz im Projekt oder im Prüfprotokoll an. Halten Sie fest, ob der Check auf einem Apple-Silicon-Mac in der nativen Architektur lief oder ob eine andere Laufzeitumgebung beteiligt war. Verwenden Sie keine persönlichen Pfade, privaten Datensätze oder Dateien aus dem Arbeitsverzeichnis einer einzelnen Person als implizite Voraussetzung.

Was muss vor R CMD check auf einem Mac bereitstehen?
Benötigt werden eine nutzbare R-Installation, der Paketquellcode und die für das Paket erforderlichen Abhängigkeiten. Enthält das Paket nativen Code, müssen zusätzlich ein passender Compiler und gegebenenfalls Header-Dateien sowie externe Bibliotheken verfügbar sein. Die konkrete Anforderung hängt vom Paket ab; die R-Dokumentation beschreibt Build und Check, während Apple Installation und Auswahl der Xcode Command Line Tools separat dokumentiert. Prüfen Sie daher nicht pauschal „Xcode vorhanden“, sondern die tatsächlich aktive Werkzeugkette (R-Handbuch zu Build und Check, Apple-Anleitung zur Installation der Command Line Tools).

Führen Sie die folgenden Prüfungen im Terminal aus und bewahren Sie die Ausgabe auf:

R --version
R --vanilla -s -e 'cat(R.version$platform, "\n"); print(R.version)'
xcode-select -p

Die ersten Befehle dokumentieren die verwendete R-Laufzeit; xcode-select -p zeigt den ausgewählten Entwicklerpfad. Falls die Command Line Tools fehlen, beschreibt Apple die Installation über die Systemeinstellungen beziehungsweise den vorgesehenen Installationsablauf. Ist ein anderer Entwicklerpfad aktiv als erwartet, prüfen Sie die Auswahl in den dokumentierten Einstellungen, statt durch Neuinstallation auf Verdacht mehrere Werkzeugketten zu verändern (Apple: Command-Line-Tools-Einstellungen konfigurieren).

Die Command Line Tools sind nicht automatisch mit einer vollständigen Xcode-Installation gleichzusetzen. Für manche Pakete reichen die Kommandozeilenwerkzeuge; andere Arbeitsabläufe können zusätzliche Komponenten erfordern. Maßgeblich sind die tatsächlich ausgeführten Build-Schritte und die aktuelle Dokumentation, nicht die Annahme, eine bestimmte Installation sei für jedes Paket erforderlich. Die R-Dokumentation zur Installation und Administration auf macOS bietet ergänzenden Kontext zur R-Umgebung, ersetzt aber nicht die Prüfung der konkreten Paketabhängigkeiten (R: Installation und Administration auf macOS).

Erst das Quellpaket bauen, dann das Archiv prüfen

Ein häufiger Fehler in der Abnahme besteht darin, nur das Entwicklungsverzeichnis zu testen. Dabei kann übersehen werden, dass benötigte Dateien nicht im späteren Paketarchiv enthalten sind oder versehentlich Dateien aus dem Arbeitsverzeichnis die Prüfung ermöglichen. Bauen Sie deshalb zuerst das Quellpaket und lassen Sie R CMD check anschließend genau dieses Archiv prüfen. Das entspricht der von R dokumentierten Abfolge für Paket-Build und Check (R-Handbuch „Writing R Extensions“, Dokumentation der R-Paketwerkzeuge).

Wechseln Sie im Terminal in das Verzeichnis, das den Paketordner enthält. Ersetzen Sie meinPaket durch den tatsächlichen Paketordnernamen:

R CMD build meinPaket
R CMD check meinPaket_1.0.0.tar.gz

Der Archivname im zweiten Befehl ist ein Beispiel und muss durch den tatsächlich erzeugten Dateinamen ersetzt werden. Verwenden Sie nicht ungeprüft eine Versionsnummer aus diesem Beispiel. Wenn der Build fehlschlägt, ist zunächst der Build-Fehler zu bearbeiten; ein Check eines nicht erzeugten oder veralteten Archivs beantwortet nicht, ob der aktuelle Quellstand abnahmefähig ist.

Speichern Sie neben dem Archiv auch die vollständige Terminalausgabe und das von R CMD check erzeugte Prüfverzeichnis. Ein kurzer Status in einer E-Mail genügt nicht, wenn später nachvollzogen werden muss, welche Tests oder Beispiele gelaufen sind. In der Dokumentation zu R CMD check sind auch Optionen und die zugehörigen Prüfschritte beschrieben; lesen Sie diese beim Einsatz zusätzlicher Argumente nach, statt Optionen aus einem früheren Projekt zu übernehmen.

Ein reproduzierbarer Ablauf sieht so aus:

1. Prüfen Sie, dass der Quellstand dem dokumentierten Commit oder Freigabestand entspricht.
2. Bauen Sie das Archiv in einer sauberen Projektkopie.
3. Notieren Sie den exakten Archivnamen und den Rückgabestatus des Build-Befehls.
4. Prüfen Sie genau dieses Archiv und sichern Sie das vollständige Protokoll.
5. Ordnen Sie jede Meldung der Phase zu, in der sie auftritt: Paketstruktur, Installation, Kompilierung, Tests, Beispiele oder Dokumentation.
6. Wiederholen Sie den Build und Check nach einer Änderung mit einem neuen, eindeutig dokumentierten Quellstand.

Der Check kann unterschiedliche Meldungskategorien ausgeben. Behandeln Sie ERROR, WARNING und NOTE nicht als austauschbare Urteile: Öffnen Sie die jeweilige Meldung, lesen Sie den betroffenen Abschnitt und prüfen Sie, ob sie durch Paketcode, fehlende Umgebungsvoraussetzungen oder eine bewusste Projektentscheidung ausgelöst wurde. Welche Konsequenz eine Meldung für eine Veröffentlichung hat, hängt zusätzlich vom Ziel und den geltenden Richtlinien ab. Für eine CRAN-Einreichung sind die aktuellen Vorgaben in der CRAN Repository Policy maßgeblich.

Kompilierungsfehler nach Ursache statt nach Vermutung eingrenzen

Besonders bei Forschungspaketen mit C-, C++- oder Fortran-Code ist ein Fehler während des Builds nicht automatisch ein Fehler im R-Code. Die Ursache kann im Paketquelltext liegen, aber auch in nicht verfügbaren Headern, einer nicht auffindbaren Bibliothek, einer abweichenden Compilerkonfiguration oder einer Architekturabweichung zwischen Komponenten. Installieren Sie daher nicht reflexartig ein zusätzliches Werkzeug, bevor der erste konkrete Fehler eingegrenzt wurde.

Wo sollten Sie bei einem Compilerfehler auf dem Mac zuerst nachsehen?
Lesen Sie zuerst die früheste aussagekräftige Fehlermeldung im Build-Protokoll und unterscheiden Sie Compilerfehler von Linkerfehlern. Ein fehlender Header deutet auf eine nicht verfügbare Entwicklungsdatei oder einen nicht gefundenen Include-Pfad; ein Fehler beim Verknüpfen kann auf eine fehlende Bibliothek oder eine inkompatible Binärkomponente hinweisen. Vergleichen Sie anschließend den aktiven Entwicklerpfad, die tatsächlich aufgerufenen Werkzeuge und die Paketvoraussetzungen. Das R-Handbuch beschreibt die Build-Umgebung und die für Paketprüfungen relevanten Abläufe; Apple dokumentiert die Auswahl der Command Line Tools.

Gehen Sie für eine erste Diagnose in dieser Reihenfolge vor:

1. Suchen Sie im vollständigen Protokoll nach der ersten konkreten Compiler- oder Linkermeldung, nicht nur nach der abschließenden Fehlermeldung.
2. Prüfen Sie, ob die dort genannte Datei zum Paket gehört oder eine externe Abhängigkeit ist.
3. Kontrollieren Sie, ob die benötigte Bibliothek und ihre Entwicklungsdateien in der dokumentierten Umgebung verfügbar sind.
4. Vergleichen Sie die Architektur der R-Laufzeit mit der Architektur der eingebundenen Bibliotheken.
5. Erstellen Sie einen minimalen reproduzierbaren Fehlerfall und testen Sie die Behebung anschließend am vollständigen Quellpaket.

Diese Reihenfolge verhindert, dass ein lokaler Erfolg durch eine undokumentierte Änderung an der Maschine entsteht. Wird eine externe Bibliothek installiert oder ein Pfad angepasst, gehört diese Information in die Umgebungsnotiz. Andernfalls kann ein späterer Check auf einem zweiten Mac scheitern, obwohl das Paket selbst unverändert geblieben ist.

Die Tabelle ist eine Diagnosehilfe, keine automatische Fehlerklassifikation. Derselbe Wortlaut kann je nach Paket unterschiedliche Ursachen haben. Dokumentieren Sie deshalb den konkreten Befehl, die erste aussagekräftige Fehlermeldung und die Änderung, mit der sich der Fehler reproduzierbar beseitigen lässt.

Tests, Beispiele und Dokumentation in einer sauberen Sitzung prüfen

Ein Paketcheck sollte nicht davon abhängen, dass eine Entwicklerin oder ein Entwickler zuvor ein bestimmtes Objekt geladen, ein persönliches Datenverzeichnis eingerichtet oder eine private Datei abgelegt hat. Starten Sie die Prüfung daher in einer sauberen Kopie und kontrollieren Sie, ob Tests, Beispiele und Vignetten alle benötigten Eingaben selbst bereitstellen oder ihre Voraussetzungen ausdrücklich beschreiben. Für bereits installierte Pakete dokumentiert R außerdem die Testmöglichkeiten der tools-Funktion testInstalledPackage; nutzen Sie sie gezielt, wenn Sie einen installierten Zustand untersuchen möchten, und verwechseln Sie diesen Test nicht mit dem vollständigen Check des Quellarchivs (R-Dokumentation zu testInstalledPackage).

Wie lässt sich ein Fehler in Hilfe-Dateien oder Vignetten lokalisieren?
Ordnen Sie die Meldung dem betroffenen Abschnitt des Prüfprotokolls zu und ermitteln Sie, ob der Fehler beim Erzeugen der Dokumentation, beim Installieren des Pakets oder beim Ausführen einer Vignette entsteht. Prüfen Sie anschließend die betroffene Quelldatei, referenzierte Dateien und die Voraussetzungen des Beispiels. Ein fehlender lokaler Datensatz ist anders zu behandeln als ein Fehler in einem R-Code-Beispiel oder in einer Dokumentationsreferenz. Nach der Korrektur muss erneut das Quellarchiv gebaut und geprüft werden, damit die Abnahme den ausgelieferten Paketinhalt statt nur eine bearbeitete Datei abdeckt.

Für wissenschaftliche Auswertungen ist außerdem wichtig, erwartete numerische Ergebnisse und Toleranzen vor der Plattformprüfung im Projekt festzulegen. Zufallszahlen, Gleitkommaoperationen und plattformspezifische Bibliotheken können Abweichungen sichtbar machen. Verwenden Sie deshalb keine nachträglich erfundene allgemeine Toleranz, nur um einen Test auf einer Plattform „grün“ zu bekommen. Vergleichen Sie das Ergebnis mit der fachlich begründeten Erwartung des Projekts und dokumentieren Sie, welche Unterschiede zulässig sind und welche auf einen Fehler hindeuten.

Soll die Prüfung regelmäßig durch ein Teammitglied ohne lokalen Mac wiederholt werden, ist eine dokumentierte Remote-Umgebung eine mögliche Ergänzung. Informationen zu einem Mac für die Paketprüfung sollten jedoch erst dann in die Planung einfließen, wenn feststeht, dass tatsächlich eine native macOS-Abnahme benötigt wird. Für Forschungsaufgaben, die keine Mac-spezifische Laufzeit voraussetzen, kann eine vorhandene Linux- oder Windows-Umgebung geeigneter sein.

Die Abnahme auf macOS arm64 abschließen und ihre Grenzen festhalten

Ein erfolgreiches Protokoll beantwortet zunächst eine begrenzte Frage: Hat der dokumentierte Quellstand unter der dokumentierten Mac-Umgebung die ausgeführten Prüfschritte bestanden? Es belegt nicht automatisch, dass andere Betriebssysteme, andere Architekturen oder sämtliche für eine Einreichung geltenden Bedingungen erfüllt sind. Ebenso ist ein lokaler Check keine Zusage, dass CRAN ein Paket annimmt; dafür müssen die aktuellen Regeln und gegebenenfalls die jeweiligen Plattformprüfungen gesondert berücksichtigt werden.

Bedeutet ein bestandener Mac-Check, dass das Paket auch unter Windows und Linux funktioniert?
Nein. Der lokale Check zeigt, wie sich das Quellpaket in der geprüften macOS-Umgebung verhält. Unterschiede bei Compilern, Systembibliotheken, Dateipfaden, verfügbaren Funktionen oder plattformspezifischem Code können auf anderen Systemen zusätzliche Fehler verursachen. Wenn Windows oder Linux zum Unterstützungsziel gehören, planen Sie für diese Plattformen eigene Prüfungen ein. Bei einer geplanten CRAN-Einreichung gleichen Sie die Ergebnisse außerdem mit der aktuellen Repository Policy und den dort geltenden Plattformanforderungen ab.

Vor der Übergabe sollte das Prüfprotokoll mindestens enthalten:

• den identifizierbaren Quellstand und den tatsächlich geprüften Archivnamen;
• die dokumentierten R- und macOS-Umgebungsangaben sowie die aktive Architektur;
• den Entwicklerpfad und relevante externe Abhängigkeiten;
• die vollständige Check-Ausgabe mit Zuordnung der Meldungen zu den Prüfschritten;
• den Bearbeitungsstand jedes Fehlers und jeder offenen Meldung;
• eine Liste der Plattformen und Bedingungen, die noch nicht geprüft wurden.

So kann die nächste Person zwischen „auf dem Mac geprüft“, „auf weiteren Zielplattformen geprüft“ und „für eine bestimmte Einreichung anhand der aktuellen Regeln vorbereitet“ unterscheiden. Diese Aussagen sollten im Übergabevermerk nicht zusammengezogen werden: Sie stehen für unterschiedliche Prüfumfänge und unterschiedliche Verantwortlichkeiten.

Wenn im Labor kein Mac verfügbar ist, prüfen Sie zuerst, ob eine native macOS-Abnahme für das konkrete Paket notwendig ist und wie lange die Umgebung tatsächlich gebraucht wird. Eine vorhandene Labor-Maschine ist bei regelmäßigem Betrieb und physischem Gerätebedarf oft die passendere Lösung; ein Remote-Mac kann für eine zeitlich begrenzte Abnahme sinnvoll sein, bringt aber zusätzliche Fragen zu Zugriffsrechten, Datenschutz, Netzverbindung und reproduzierbarer Konfiguration mit sich. Einen Überblick über NodeMini und verfügbare Mac-Umgebungen können Arbeitsgruppen nutzen, um den temporären Bedarf einzuordnen, statt aus einem einzelnen Check sofort eine dauerhafte Beschaffung abzuleiten.

Für die Abnahme gilt damit eine klare Reihenfolge: Umgebung festhalten, Quellarchiv bauen, dieses Archiv prüfen, Compiler- und Testfehler gezielt eingrenzen und den nicht geprüften Plattformumfang ausdrücklich benennen. Fehlt dem Labor nur vorübergehend ein Mac, kann eine zeitlich begrenzte NodeMini-Umgebung die native Prüfung ermöglichen, ohne einen Kauf vorwegzunehmen. Bei dauerhaftem, regelmäßigem Betrieb oder Bedarf an physischen Schnittstellen sollte dagegen eine lokale Lösung geprüft werden; bei fehlendem macOS-Bezug reicht möglicherweise die vorhandene Plattform. Prüfen Sie bei NodeMini die passende Mac-Umgebung für eine befristete Abnahme erst dann, wenn Projektumfang und Prüftermin feststehen.