1 Punkte von GN⁺ 2024-09-22 | 2 Kommentare | Auf WhatsApp teilen
  • Ich mag Makefiles. Ich benutze sie seit über 10 Jahren zum ersten Mal. Schon damals wirkten sie wie eine alte Technologie. Im Lauf der Zeit kamen neue Build-Tools auf und verschwanden wieder, aber Makefiles wurden weiterhin verwendet. Als ich an Projekten mitarbeitete, gewöhnte ich mich daran, und irgendwann begann ich, sie zu mögen. Heute ist es das erste Automatisierungstool, das ich verwende, wenn ich ein neues Projekt starte.

  • Der Grund, warum ich Makefiles mag, ist, dass sie einer informellen Konvention folgen, mit der sich derselbe Befehlssatz umsetzen lässt. Wenn ich auf ein neues Projekt stoße und eine Datei namens Makefile sehe, führe ich make oder make build aus und danach make install; dann wird das Projekt gebaut und eingerichtet. Oder ich bekomme Informationen über zusätzliche Schritte.

  • Ich versuche, dieselbe Konvention auch in meinen Projekten anzuwenden. Wenn ich einen alten Projektordner öffne und make dev ausführe, werden alle nötigen Schritte erledigt, um das Projekt zu bauen und den Entwicklungsserver zu starten. Da ich mit verschiedenen Technologien gearbeitet habe, gab es für jede Technologie andere Befehle. Mit einem Makefile lassen sich auch Projekte leicht verwalten, die ich monatelang oder jahrelang nicht angefasst habe.

  • Makefiles sind einfach. Ich verwende keine Bedingungen, Flags oder andere komplexe Funktionen. Die meisten Aufgaben bestehen aus einem oder mehreren Shell-Befehlen. Man könnte auch ein Bash-Skript mit einigen Funktionen schreiben, aber ein Makefile ist einfacher und schneller zu schreiben.

  • Die meisten persönlichen Projekte enthalten die folgenden allgemeinen Aufgaben:

    • dev: Entwicklungsserver starten
    • build: Projekt bauen (falls ein Build-Schritt erforderlich ist)
    • deploy: Projekt deployen/veröffentlichen
  • Dieser Blog hat ein einfaches Makefile mit nur einem Target:

    dev:  
      npm run dev  
    
  • In komplexeren Projekten verwende ich Makefiles wie dieses:

    # Entwicklungsserver starten  
    dev:  
      bundle exec jekyll serve --unpublished -w --config _config.yml,_config-dev.yml --livereload  
    
    # Assets bauen  
    build:  
      npm run gulp build  
    
    # Bestimmte Ordner überwachen und Assets verarbeiten  
    watch:  
      npm run gulp watch -- --wip  
    
    # Website lokal bauen, verschlüsseln und auf dem Netlify-Server deployen  
    deploy:  
      JEKYLL_ENV=production bundle exec jekyll build; \  
      make encrypt; \  
      netlify deploy --prod  
    
    # Ordner "_site" verschlüsseln  
    encrypt:  
      npx staticrypt _site/*.html -r -d _site  
    
  • Im obigen Beispiel wird die Existenz von phony Targets ignoriert. Wenn es eine Datei namens dev, build, watch, deploy oder encrypt gibt, funktioniert das Makefile möglicherweise nicht wie erwartet.

  • GNU Make ist sehr verbreitet. Unter Linux ist es wahrscheinlich bereits installiert. Auch auf meinem MacBook kann ich mich nicht erinnern, es explizit installiert zu haben. Vermutlich wurde es zusammen mit anderen Tools installiert. Make ist einfach und hat weniger zusätzliche Abhängigkeiten als andere Build-Tools. Das kann in eingeschränkten Umgebungen nützlich sein. Wahrscheinlich ist Make bereits vorhanden. Falls nicht, kann man die Befehle aus dem Makefile auch manuell in der Shell ausführen.

  • Das ist kein Widerspruch gegen andere Build-Tools. Wenn ich ein neues Build-Tool entdecke, finde ich das spannend. Trotzdem verwalte ich mit Make weiterhin verschiedene Tools.


Zusammenfassung von GN⁺

  • Makefiles bieten in unterschiedlichen Projekten einen konsistenten Befehlssatz und erleichtern so die Verwaltung.
  • Mit ihrer einfachen Syntax und wenigen Abhängigkeiten sind sie auch in eingeschränkten Umgebungen nützlich.
  • Sie lassen sich zusammen mit verschiedenen Build-Tools verwenden und sind dadurch sehr flexibel.
  • Werkzeuge mit ähnlicher Funktion sind unter anderem CMake, Ninja und Gradle.

2 Kommentare

 
kayws426 2024-09-22

Wenn keine Abhängigkeiten definiert sind, bietet ein Ersatz des makefile durch justfile eine bessere Benutzerfreundlichkeit.

 
GN⁺ 2024-09-22
Hacker-News-Kommentare
  • Ermutigung zur Nutzung von Make

    • Die Meinung, man solle sich nicht entmutigen lassen, wenn man Make „falsch“ verwendet
    • Die Stärke von Make liegt in seiner Einfachheit, und bei kleinen Projekten ist das kein großes Problem
    • In den meisten Fällen muss man sich nicht um den „richtigen“ Weg kümmern, und es kommt nur so viel Komplexität hinzu wie nötig
  • Probleme mit Makefiles

    • Makefiles sind weniger schlecht als andere Build-Systeme, haben aber immer noch viele Probleme
    • Die Hauptprobleme von Build-Systemen:
      • Zu grundlegend: Bei komplexen Projekten entsteht Verwirrung
      • Zu komplex: Es wird zu viel Vorwissen und Pflege verlangt
      • Fehlende Standardbibliothek: Man muss alles selbst definieren
      • Zu eingeschränkt: Wenn sich die Anforderungen ändern, muss man zu einem anderen System wechseln
      • Zu viel Magie: Ein Merkmal schlecht entworfener Systeme
      • Verschlüsselte oder inkonsistente Syntax
  • Vorteile von Make

    • Die Meinung von jemandem, der Make mag
    • Make ist eine einfache DSL, also eine Sammlung von Befehlen zur Umwandlung von Dateien
    • Das geht auch mit Bash oder einer anderen Shell, aber mit Make ist es einfacher
  • Verwendung von PHONY-Zielen

    • Es wird keine mtime-basierte Abhängigkeitsverfolgung verwendet
    • Ziele müssen als PHONY definiert werden
    • In letzter Zeit wurde auf just und justfiles umgestiegen, weil sie einfacher zu verwenden sind
  • Hitzige Debatte über Make

    • Make löst Debatten aus wie der Krieg vi vs. emacs
    • Es ist klug, ein Makefile als Treiber für das Build-System auf oberster Ebene zu verwenden
    • Selbst wenn andere Build-Tools verwendet werden, kann man mit einem Makefile standardisieren
  • Vielfältige Einsatzmöglichkeiten von Make

    • Make wird für die Automatisierung verschiedenster Aufgaben verwendet
    • Ein Makefile wird für den Build und das Deployment einer persönlichen Website genutzt
    • Make wird über Git push und Git-Hooks aufgerufen
    • Ein Makefile wird zum Hochladen und Verwalten von PDF-Dateien verwendet
  • Grenzen von Make und Alternativen

    • Make ist als Task-Runner in Ordnung, aber es gibt bessere Alternativen
    • Make/Makefiles sind nicht standardisiert
    • Abhängigkeiten können nicht aufgelöst werden, daher sind configure-Skripte nötig
    • Es wird mtime verwendet, um zu prüfen, ob Eingaben aktuell sind, was jedoch Probleme verursachen kann
    • Es wurde nach der Unix-Philosophie entworfen, hat aber Grenzen in modernen Build-Systemen
  • Umstieg auf Justfiles

    • Es wurde auf Justfiles umgestiegen, um die Komplexität von Makefiles zu vermeiden
  • Einfache Nutzung von Makefiles

    • Die Meinung, die einfache Nutzung von Makefiles zu unterstützen
    • Man kann sie gemeinsam nutzen, ohne alles perfekt gelernt zu haben
    • Es wurde die Erfahrung geteilt, dass GitLab-CI-Pipelines Makefiles ersetzt haben