rhabarber1848 hat geschrieben:@Barf: Sehe ich das richtig, dass Du statt
--with-features=LIST
comma seperated list of tools, plugins and additional features,
allowed values: cdkvcinfo, dboxshot, dropbear, dvbsnoop(*), dvbsub, esound, fbshot, getrc,
hddtemp (needs IDE), input, ipkg, lcshot or lirc (both dbox2-only), msgbox, openvpn, procps,
satfind, shellexec, sqlite, sysinfo, tuxcal, tuxcom(*), tuxmail(*), tuxtxt(*), tuxwetter
(*) -> enabled by default
lieber folgendes sehen würdest:
--enable-cdkvcinfo (unverändert)
--enable-dboxshot
--enable-dropbear
...
um den Patch autoconf-konform und rückwärtskompatibel zu halten?
Ja. Aber "autoconf-konform und rückwärtskompatibel" ist kein heiliges Graal für mich: ich bin gegen --with-feature weil es eine Verschlechterung darstellt. --with-feature ist fast nur eine syntaktische Modifikation. "fast" bedeutet, dass --with-feature weniger Möglichkeite bietet als das, was es ersetzen soll: Die Möglichkeit, ein Feature ABzuwählen fehlt, deswegen(?) der Bedarf/Wünsch alle Defaults auf "aus" zu setzen.
Ich möchte halt gerne den Umfang der customisation-Skripts reduzieren,
ohne mit anderen Dateien wie $CONFIG_SITE anzufangen.
Jetzt vermischst du neue nützlige Optionen/Features mit --enable-* nach --with-feature Migration. Das Erste bin ich definitiv nicht dagegen, das Zweite schon. Ehrlich gesagt, falls damit die Kommandozeile von, sagen wir 400 Zeichen zu 350 schrümpft, behauptest du, dass du damit ein Problem löst?
rhabarber1848 hat geschrieben:Für Barf ist es wichtig, dass sich
an der Liste der aktivierten Plugins nichts ändert.
Nö, dass habe ich nicht gesagt, und ich bin auch nicht der Meinung. Erstmals finde ich die Diskussion über welche Optionen Default sein soll und welche nicht eine anderes Thema, das irgendwo anderes diskutiert werden soll. Für mich ist es wichtig, dass die Wahl der Defaults flexibel und pragmatisch ist, bei Bedarf angepasst werde kann, und dass die Tools dies auch unterstützt (-> K.O.-Kriterium für --with-feature, am mindestens die aktuelle Implementierung). Also bin ich gegen alle Default off, (möglicherweise) theoretisch elegant, aber gar nicht praktisch. Lass mich in einem (IMHO realistisches) Beispiel erläutern:
Nehmen wir an, Jemanden implementiert eine Möglichkeit den http-Server in Neutrino abzuwählen. Klar soll das Default Inklusion des http-Servers sein, sonst wurde eine Menge Leute sich ärgern, und fragen was los ist. Also ist hier "an" die vernünftige Defaultwahl, in Wiederspruch zu "alles aus". Dann sagt vielleicht Jemanden: "Dann soll die Option negativ sein, also z.B. 'disable-neutrino-http-server'". Wieder schlecht: Negative Optionen/Variabeln sind problematisch, am mindesten wenn sie negiert wird. Nicht nur sieht
Code: Alles auswählen
#ifdef !disable_httpserver
(code für den http-server)
#endif
häßlich aus, es ist auch deutlich mehr fehlerträchtig, ins besonderes falls && und || in der Spiel kommt (
de Morgan beachten!). Noch schlimmer (oben habe ich Defaults als veränderbar gefordert): Sollte man in den Quellen vielleicht umfassende Änderungen durchführen, nur weil ein Default sich geändert hat?
dbt hat geschrieben:Dran denken, wenn man alles rückwärtskompatibel haben will, wird es unter Umständen immer schlechter mit der Wartung
Wartung wird schwierig, sobald Information nichtlokal ist (z.B. wo defaultwerte, Kode zu setzen, Dokumentation verteilt ist), und das System viel Redundanz enthält. Ich habe in der Tat den Patch studiert, und schätze ihn als diesbezüglich schlechter als der originale Kode ein.
Man stelle sich mal vor, wenn man Newmake mit Oldmake rückwärtskompatible gemacht hätte. Aua, Aua
Newmake war eine umfassende Umarbeitung des Buildsystem, mit mit erhebliche funktionelle Erweiterungen. --with-feature eine syntaktische Umarbeitung, mit funktionelle Einschränkungen.
Viele Probleme mit "oldmake" war in Kern, dass die Authoren das Gnu Buildsystem (automake/autoconf/libtool) nicht verstanden haben, und anstatt diverse ad-hoc-Lösungen von schlechten Qualität gebastelt haben. newmake hat anstatt versucht, diese heimgestrichte Lösungen zu verwerfen, und das Gnu Makesystem systematisch einzusetzen.
rhabarber1848 hat geschrieben:Du kannst bei configure für eine bereits intern aktive Option, wie z.B. tuxtxt,
auch --enable-tuxtxt schreiben, es ändert zwar nichts, ist aber zukunftsicherer,
da Du nicht von den defaults in cdk/configure abhängig bist. Nur macht es keinen
Sinn, --enable-tuxtxt als configure-Helptext zu schreiben, besser ist es, auf
die --disable-Option hinzuweisen um nach außen hin bereits hier zeigen zu können,
dass Tuxtxt im Standardimage immer dabei ist.
Nicht zu vergessen: --disable-foo ist nicht anderes als ein Synonym für --enable-foo=no.
von mir.