Menükonfiguration pflegen

Einer der ersten Schritte jedes Freetz-Benutzers ist die Auswahl der gewünschten Firmware (FW)-Konfiguration mit make menuconfig. Die Menükonfiguration (MK) ist mithin die primäre Benutzerschnittstelle neben der Linux-Shell für alle Nicht-Entwickler. Fehler und Unstimmigkeiten, welche dort auftauchen, können bestenfalls zu Verwirrung und Fragen im IPPF Freetz-Forum führen, aber auch zu seltsamen Warnungen auf der Konsole nach dem Speichern der Konfiguration, zu fehlenden oder überflüssigen FW-Bestandteilen oder schlimmstenfalls zu Freetz-Boxen, die nicht mehr booten oder in Reboot-Schleifen festhängen. In jedem Fall entsteht Support-Aufwand. Am billigsten sind, gemäß dem agilen Mantra “fail early”, jedoch Fehler, die frühestmöglich bemerkt werden oder am besten gar nicht erst entstehen. Die Pflege der Menükonfiguration ist ein wichtiger Qualitäts-Baustein unseres Projektes.

Einstieg

Pflichtlektüre jedes Entwicklers, bevor er zum ersten Mal die MK anpaßt, sollte die tools/config/kconfig-language.txt sein. Dort werden Syntax-Features und deren Gebrauch grundlegend erklärt. Die Beschreibung entstammt der Dokumentation des Linux-Kernels, welchem wir (und auch andere quelloffene Projekte) diese Art der MK und die dazu notwendigen Werkzeuge entlehnt haben.

Die wichtigste Dateien und Make-Targets, mit welchen wir es im Folgenden zu tun haben werden, sind

Siehe vorerst #1532 , insbes. Kommentare Nr.

Syntax-Fehler in MK-Dateien finden

Wir sehen einen Fehler wie diesen:

	$ make menuconfig

	Config.in.cache:4951: syntax error
	Config.in.cache:4950: unknown option "xconfig"
	Config.in.cache:4951:warning: prompt redefined
	make: *** [menuconfig] Error 1

Gemäß Beschreibung in r8466 gibt es zwei Wege, bei einem von make menuconfig angezeigten Syntax-Fehler schnell die fehlerhafte Stelle zu finden:

  1. In Config.cache.in direkt zu der Fehlerzeile 4950 springen, die auf der Konsole angezeigt wurde. Von dort aus rückwärts(!) suchen nach INCLUDE_BEGIN - voilà, dort steht der Dateiname, wo die fehlerhafte MK zu finden ist.
  2. make menuconfig-nocache aufrufen und die problematische Datei (make/davfs2/Config.in) direkt von der Konsole ablesen:

        $ make menuconfig-nocache
    
        make/davfs2/Config.in:2: syntax error
        make/Config.in:84: missing end statement for this entry
        Config.in:851: missing end statement for this entry
        make/davfs2/Config.in:1: invalid statement
        make/davfs2/Config.in:2: unexpected option "bool"
        make/davfs2/Config.in:3: unexpected option "select"
        make/davfs2/Config.in:4: unexpected option "select"
        make/davfs2/Config.in:5: unexpected option "select"
        make/davfs2/Config.in:6: unexpected option "select"
        make/davfs2/Config.in:7: unexpected option "select"
        make/davfs2/Config.in:8: unexpected option "select"
        make/davfs2/Config.in:9: unexpected option "default"
        make/davfs2/Config.in:10: invalid statement
        make/davfs2/Config.in:11: unknown statement "davfs"
        make/davfs2/Config.in:12: unknown statement "WebDAV"
        make/davfs2/Config.in:13: unknown statement "HTTP"
        make/davfs2/Config.in:14: unknown statement "resources"
        make/Config.in:199: unexpected end statement
        Config.in:862: unexpected end statement
        make: *** [menuconfig-nocache] Error 1
    

Syntax-Hervorhebung für MK-Dateien

Gemäß tools/developer/kconfig.pygments.patch habe ich (Alexander Kriegisch, kriegaex) zunächst einen sog. Lexer für Pygments gebaut (siehe auch Pygments-Doku), welcher es ermöglicht, MK-Dateien mit Syntax-Hervorhebung zu versehen. Pygments wird von Trac, also dem System, auf welchem unser Wiki und der Repository Browser basieren, automatisch benutzt, sofern es installiert ist.

Trac erkennt den MIME-Typ einer Datei aber nur aufgrund der Endung (also z.B. .py, .sh, .pl, .c, .h) oder aufgrund Infos wie Shebang oder Vi-/Emacs-Header, und das ist ein Problem bei MK-Dateien, da es keine standardisierte Dateiendung im Allgemeinen und auch nicht bei uns im Projekt gibt. Unsere einzige Chance ist es, den Wildwuchs an Dateinamen (z.B. Config.in, external.in, standard-modules.in, external.in.libs) so im Zaum zu halten, daß man mit Regex Matching die entsprechenden Dateien identifizieren kann. Das ist Stand heute möglich, allerdings beherrscht Trac von Haus aus kein Regex Matching, weswegen tools/developer/mime_map_patterns.trac.patch notwendig wird. (Anm.: Bevor es Patch 2 gab, war es notwendig, in SVN die Eigenschaft svn:mime-type für jede MK-Datei manuell zu setzen, was inzwischen zum Glück obsolet ist, aber auch nicht schaden würde.)

Auf unserem Webserver sind beide Patches nebst der notwendigen Konfiguration in trac.ini aktiv, so daß MK-Dateien aus dem SVN-Repository automatisch mit Syntax-Hervorhebung versehen werden.

Noch ein kleiner Tip: Wie man Syntax Highlighting im Trac-Wiki direkt in Code-Blocks einsetzt, sieht man hier direkt im Artikel für MK- und Shell-Code: Entweder man erwähnt am Anfang des Code-Blocks mit führendem Shebang den MIME-Typ (text/x-kconfig, übrigens selbst erfunden und kein allgemeiner Standard) oder das in trac.ini konfigurierte Schlüsselwort kconfig, also in etwa so:

	}

Oder so:

	}