Mein kleines Allerlei
- Ersteller cuma
- Erstellt am
Hier noch ein Screenshot dazu. Einen Langzeittest dazu gibt es aber leider noch nicht, ich hoffe mal dass das alles so läuft. Es ist angedacht damit zu sehen wann eine Box rebootet wurde (bei mir manchmal "einfach so") bzw ob sie überhaupt eingeschaltet war.
PS: Dass die Zeit bei einem längernen Zeitraum etwas niedriger ist ist normal, da diese Daten nicht so oft wie die von kürzeren Zeiträumen geupdatet werden!
PS: Dass die Zeit bei einem längernen Zeitraum etwas niedriger ist ist normal, da diese Daten nicht so oft wie die von kürzeren Zeiträumen geupdatet werden!
Zuletzt bearbeitet:
Fix für Uptime Erweiterung von RRDstats
Die Aufzeichnung endet nach 100 Stunden. Hier ein Patch zur Erweiterung auf über 10 Jahre. Die Datei upt_??.rrd muss gelöscht werden oder mittels "rrdtool tune /pfad/zur/datei/upt_??.rrd -a uptime:99999" geupdated werden!
Bitte einchecken
Die Aufzeichnung endet nach 100 Stunden. Hier ein Patch zur Erweiterung auf über 10 Jahre. Die Datei upt_??.rrd muss gelöscht werden oder mittels "rrdtool tune /pfad/zur/datei/upt_??.rrd -a uptime:99999" geupdated werden!
Bitte einchecken
Zuletzt bearbeitet:
Der Patch greift nur beim Erstellen der rrd. Wenn es die Datei also schon gibt ändert er nichts. Wenn man die Datei mit "tune" anpasst braucht man den Patch nicht. Wie auf dem Bild zu sehen, werden Daten > 100 Stunden einfach nicht angenommen. Die Daten später wurden erst nach dem "tune" wieder geloggt.
Neue Spielereien
So, ich hab mal wieder etwas Zeit gefunden ein bisschen zu basteln.
Im 1. Posting habe ich "araw" hinzugefügt, ein Skript zum Bearbeiten von schreibgeschützden Dateien.
Ausserdem noch die Integration des "external" ins menuconfig. Damit können aus einem zu grossen Image Dateien ausgelagert werden. Betatest, aber nur Mut! :hehe:
Anwendung:
-Patch im Freetz Verzeichnis mit "patch -p0 < /derpfad/external.patch" anwenden.
-bei "advanced" external aktivieren und den entsprechenden Pfad eingeben
-dann noch die Datei "external.cfg" im Freetz Verzeichnis mit den rauszuwerfenden Dateien füttern. (die 1. Zeile hat keine Sonderbedeutung mehr)
Ich hab leider keine Möglichkeit gefunden, im menuconfig beliebig viele Dateien einzugeben, deshalb momentan noch die externe Datei. Hat dazu vielleicht jemand eine Idee??
So, ich hab mal wieder etwas Zeit gefunden ein bisschen zu basteln.
Im 1. Posting habe ich "araw" hinzugefügt, ein Skript zum Bearbeiten von schreibgeschützden Dateien.
Ausserdem noch die Integration des "external" ins menuconfig. Damit können aus einem zu grossen Image Dateien ausgelagert werden. Betatest, aber nur Mut! :hehe:
Anwendung:
-Patch im Freetz Verzeichnis mit "patch -p0 < /derpfad/external.patch" anwenden.
-bei "advanced" external aktivieren und den entsprechenden Pfad eingeben
-dann noch die Datei "external.cfg" im Freetz Verzeichnis mit den rauszuwerfenden Dateien füttern. (die 1. Zeile hat keine Sonderbedeutung mehr)
Ich hab leider keine Möglichkeit gefunden, im menuconfig beliebig viele Dateien einzugeben, deshalb momentan noch die externe Datei. Hat dazu vielleicht jemand eine Idee??
Zuletzt bearbeitet:
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Zunächst mal einen dicken Lob, dass du endlich "config.in" angetastet hast, was ich schon länger machen wollte. Es fehlt aber wie immer an der Zeit.
cuma, wollen wir doch vielleicht outsourcer und external zusammenführen? Ich sehe da ein kleines Problem mit der Inkompatibilität der config-Dateien. Kannst du bitte ein Beispiel deiner "external.cfg" hier posten? Ich schreibe bei mir z.B. noch die Rechte explizit rein und Zielpfad der ausgelagerten Datei. Ferner mache ich pro Paket jeweils eine separate config-Datei. Bei dir liegt alles in einer Datei. Was wir beide nicht angetastet haben ist die Auslagerung kompletter Verzeichnisse. Wäre in einem oder anderen Fall sicherlich sinnvoll.
Zu Idee mit Menugestaltung. Ich würde es so machen: Pro Paket eine cfg-Datei, die aussagekräftig nach Paket benannt ist. Im menuconfig kann man dann das Verzeichnis mit den cfg-Dateien auslesen und Namen darstellen. Neben jedem Namen ein Hacken, wenn es ausgelagert werden muss. Für die cfg-dateien hier ein Thread aufmachen, wo alle sie posten können. cfg-Dateien nach und nach in trunk einpflegen. Die Anfänger beglücken sich dann mit vorgefertigten cfg-Dateien (soweit vorhanden). Die Fortgeschrittenen können eigene cfg-dateien erstellen oder vorhandene erweitern.
MfG
cuma, wollen wir doch vielleicht outsourcer und external zusammenführen? Ich sehe da ein kleines Problem mit der Inkompatibilität der config-Dateien. Kannst du bitte ein Beispiel deiner "external.cfg" hier posten? Ich schreibe bei mir z.B. noch die Rechte explizit rein und Zielpfad der ausgelagerten Datei. Ferner mache ich pro Paket jeweils eine separate config-Datei. Bei dir liegt alles in einer Datei. Was wir beide nicht angetastet haben ist die Auslagerung kompletter Verzeichnisse. Wäre in einem oder anderen Fall sicherlich sinnvoll.
Zu Idee mit Menugestaltung. Ich würde es so machen: Pro Paket eine cfg-Datei, die aussagekräftig nach Paket benannt ist. Im menuconfig kann man dann das Verzeichnis mit den cfg-Dateien auslesen und Namen darstellen. Neben jedem Namen ein Hacken, wenn es ausgelagert werden muss. Für die cfg-dateien hier ein Thread aufmachen, wo alle sie posten können. cfg-Dateien nach und nach in trunk einpflegen. Die Anfänger beglücken sich dann mit vorgefertigten cfg-Dateien (soweit vorhanden). Die Fortgeschrittenen können eigene cfg-dateien erstellen oder vorhandene erweitern.
MfG
McNetic
Mitglied
- Mitglied seit
- 7 Feb 2007
- Beiträge
- 674
- Punkte für Reaktionen
- 0
- Punkte
- 16
Ich würde darauf aufbauend vorschlagen, die cfg-Dateien analog zu den .language-Dateien im make-Ordner der Pakete unterzubringen (könnte z.B. .external heissen). Zusätzlich könnte man ein zentrales Verzeichnis für manuell angelegte zusätzliche cfg-Dateien vorsehen, was auch vom Menuconfig ausgewertet wird, falls möglich.
Hallo,
mit der Zeit ist bei mir auch so eine Sache. Momentan stehen wieder Klausuren an und bis zur nächsten ists jetzt noch 1 Woche, so dass ich heut mal ein Bastelmittag eingelegt hab.
Hier zunächst mal ein Auszug meine external.cfg:
(Das sind momentan so ~6MB)
Welche Daten sind in deiner cfg?
Es wird also einfach der volle Pfad der Datei angegeben die rausgenommen werden soll. Um die Berechtigungen braucht man sich dabei keine Sorgen zumachen, da die Dateien aus dem build/modified/filesystem kommen (EDIT: Und bei FTP Übertragung neu gesetzt werden). Der Pfad wohin ausgelagert werden soll wird einmalig im menuconfig angelegt. Dieser braucht nicht im PATH zu stehen, da Links an die Stelle der original Dateien kommen. Einen Pfad finde ich für mich besser, da ich ein Skript nutze, welches mir zuerst den "external" Ordner per FTP auf die Box kopiert, diese rebootet und das passende Image dazu flasht. Wie nutzte du denn die verschiedenen Pfade?
Auslagerung von Verzeichnissen funktiniert (nach einer kleinen Änderung, siehe Anhang) auch, ich habs aber jetzt erst ausprobiert da ich noch keine Anwendung dafür hatte. Wo könnte man das denn nutzen?
Eine eigene Datei pro Paket findie ich eine ganz gute Idee. Darin könnten dann die "auslagerbaren" Dateien stehen. Dann vielleicht noch eine zentrale Datei mit allen Paketen die auslagern können und eine solche Konfiguartionsdatei haben. Dann müsste das menuconfig eine Liste generieren, in der man dann unter dem Menüpunkte external anwählen kann welches Paket aus dem Image rausgenommen werden soll. Das wär dann optimal Anfänger kompatibel. Nur das wie scheint mir hier das Problem zu sein..
mit der Zeit ist bei mir auch so eine Sache. Momentan stehen wieder Klausuren an und bis zur nächsten ists jetzt noch 1 Woche, so dass ich heut mal ein Bastelmittag eingelegt hab.
Hier zunächst mal ein Auszug meine external.cfg:
Code:
/usr/bin/tcpdump
/usr/sbin/strace
/usr/sbin/ltrace
/usr/lib/libelf.so.0.8.10
/usr/bin/ldd
/usr/bin/lsof
/usr/sbin/mtr
/lib/libresolv-0.9.28.so
/usr/lib/libncurses.so.5.6
/usr/bin/netcat
/usr/bin/lynx
/usr/bin/wput
/usr/bin/rrdtool
/usr/lib/librrd.so.2.0.13
/usr/lib/libfreetype.so.6.3.16
/usr/lib/libart_lgpl_2.so.2.3.19
/usr/lib/libpng12.so.0.10.0
/sbin/smbd
/sbin/nmbdWelche Daten sind in deiner cfg?
Es wird also einfach der volle Pfad der Datei angegeben die rausgenommen werden soll. Um die Berechtigungen braucht man sich dabei keine Sorgen zumachen, da die Dateien aus dem build/modified/filesystem kommen (EDIT: Und bei FTP Übertragung neu gesetzt werden). Der Pfad wohin ausgelagert werden soll wird einmalig im menuconfig angelegt. Dieser braucht nicht im PATH zu stehen, da Links an die Stelle der original Dateien kommen. Einen Pfad finde ich für mich besser, da ich ein Skript nutze, welches mir zuerst den "external" Ordner per FTP auf die Box kopiert, diese rebootet und das passende Image dazu flasht. Wie nutzte du denn die verschiedenen Pfade?
Auslagerung von Verzeichnissen funktiniert (nach einer kleinen Änderung, siehe Anhang) auch, ich habs aber jetzt erst ausprobiert da ich noch keine Anwendung dafür hatte. Wo könnte man das denn nutzen?
Eine eigene Datei pro Paket findie ich eine ganz gute Idee. Darin könnten dann die "auslagerbaren" Dateien stehen. Dann vielleicht noch eine zentrale Datei mit allen Paketen die auslagern können und eine solche Konfiguartionsdatei haben. Dann müsste das menuconfig eine Liste generieren, in der man dann unter dem Menüpunkte external anwählen kann welches Paket aus dem Image rausgenommen werden soll. Das wär dann optimal Anfänger kompatibel. Nur das wie scheint mir hier das Problem zu sein..
Zuletzt bearbeitet:
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Mein Outsourcer legt seine Config-dateien unter tools/outsourcer. Es gibt eine Übersichtsdatei "packages.conf":
daneben die eigentliche Configuration für outsourcer selbst "outsourcer.conf":
und dann im Unterverzeichnis "packages" befinden sich die dazugehörigen conf-Dateien. Als Beispiel hier eine auslagerung für MC "mc.conf":
Also, alles schön strukturiert. Im Skript werden alle möglichen Fälle abgefangen, wenn die Dateien nicht existieren usw. Deswegen sieht outsourcer etwas ausgeblasen aus. Dementsprechend werden auch alle möglichen Fehler-/Erfolgsmeldungen ausgegeben.
Der Hauptunterschied ist, dass ich noch die Zielpfade in die config-Datei schreibe. Die Idee kommt vom Downloader, weil ich ursprünglich versucht hatte die Dateien aus "lib" auch nach "lib" und von "bin" auch nach "bin" auszulagern. Theoretisch gibt es mod/lib mod/bin usw. und es sollte dort nach den Dateien gesucht werden. Klappt aber leider aus diversen Gründen nicht. Daher setze ich die symlinks in die Firmware, so wie du es auch machst.
Ich finde es aber etwas strukturierter und übersichtlicher, wenn man auch auf dem Stick wenigstens bin, sbin und lib findet. Daher getrennte Pfadangabe.
Zum Auslagern kompletter Verzeichnisse schwebt mir z.B. vor eventuell WEBIF (egal ob von AVM oder FREETZ) auszulagern. Eher nicht platzhalber, sondern damit man dort RW-Zugriff hat. Ansonsten gibt es Pakete, wie z.B. "callmonitor", die fast alle Dateien in einem Unterverzeichnis verbergen, sodass das Auslagern dadurch deutlich einfacher wird (wiederum will ich nicht jetzt "callmonitor" auslagern, war nur ein Beispiel).
MfG
Code:
# outsourcer active packages for ds-mod make routine
mc
openvpn
# testpackage1
# testpackage2daneben die eigentliche Configuration für outsourcer selbst "outsourcer.conf":
Code:
#!/bin/bash
# outsourcer config file using sh syntaxis
#
# build directory for unpacked modified firmware
BUILD_FS='build/modified/filesystem'
# directory for outsourced files
OUT_DIR='outboard'
# file name for downloader configuration
OUT_CONF='downloader.conf'und dann im Unterverzeichnis "packages" befinden sich die dazugehörigen conf-Dateien. Als Beispiel hier eine auslagerung für MC "mc.conf":
Code:
# outsourcer package configuration
#
# Format:
# dir-in-modified-root/filename /dir-on-the-box
# Example:
# usr/bin/mc.bin /mod/bin
#
usr/bin/mc.bin /mod/bin
usr/lib/libglib-1.2.so.0.0.10 /mod/libAlso, alles schön strukturiert. Im Skript werden alle möglichen Fälle abgefangen, wenn die Dateien nicht existieren usw. Deswegen sieht outsourcer etwas ausgeblasen aus. Dementsprechend werden auch alle möglichen Fehler-/Erfolgsmeldungen ausgegeben.
Der Hauptunterschied ist, dass ich noch die Zielpfade in die config-Datei schreibe. Die Idee kommt vom Downloader, weil ich ursprünglich versucht hatte die Dateien aus "lib" auch nach "lib" und von "bin" auch nach "bin" auszulagern. Theoretisch gibt es mod/lib mod/bin usw. und es sollte dort nach den Dateien gesucht werden. Klappt aber leider aus diversen Gründen nicht. Daher setze ich die symlinks in die Firmware, so wie du es auch machst.
Ich finde es aber etwas strukturierter und übersichtlicher, wenn man auch auf dem Stick wenigstens bin, sbin und lib findet. Daher getrennte Pfadangabe.
Zum Auslagern kompletter Verzeichnisse schwebt mir z.B. vor eventuell WEBIF (egal ob von AVM oder FREETZ) auszulagern. Eher nicht platzhalber, sondern damit man dort RW-Zugriff hat. Ansonsten gibt es Pakete, wie z.B. "callmonitor", die fast alle Dateien in einem Unterverzeichnis verbergen, sodass das Auslagern dadurch deutlich einfacher wird (wiederum will ich nicht jetzt "callmonitor" auslagern, war nur ein Beispiel).
MfG
Mojn, hab es anfängerfreundlicher gemacht. Einen jeweiligen Zielpfad kann man noch nicht eingeben, für die Realisierung fehlt mir noch ne Idee. Im menuconfig werden mögliche Pakete zur Auswahl gestellt. Ausserdem hat jedes Paket sein eigenes Skript. Was haltet ihr davon? Auch eigene Dteien/verzeichnisse könne angegeben werden.
Ausserdem wollte ich das Skrip an sich nach tools/ auslagern, dann hatte ich aber dummerweise die Variablen nicht mehr verfügbar
Ausserdem wollte ich das Skrip an sich nach tools/ auslagern, dann hatte ich aber dummerweise die Variablen nicht mehr verfügbar
Zuletzt bearbeitet:
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
bis auf die Passage
finde ich deine Idee mit external.in-Dateien gut. Wie gesagt, wenn du schon die "external.in"-Dateien verwendest, muss man von dort die Konfiguration auslesen. Es ist schlecht in der Zentralen Config.in z.B. die absoluten Namen der Bibliotheken stehen zu haben.
Mit Zielverzeichnissen muss man sehen. Eigentlich kann man es automatisieren: Aus dem Hauptpfad die Pfadangaben auslesen (z.B. "usr/lib" oder "usr/bin") und dann dem Hauptpfad dazuaddieren. Im Falle des RAMs würde der Hauptpfad "/mod" heißen, im Falle des USB-Sticks dann in etwa "/media/uStor01/external". Nach der Zusammensetzung hießen dann die Pfade (als Beispiel):
worauf man dann die symbolischen Links erstellt.
Ich wäre an meiner Seite mit Outsourcer und Downloader damit einverstanden und du hättest auch auf dem USB-Stick einen LINUX-conformen Verzeichnisbaum, was bei mehreren Dateien nur von Vorteil wäre.
Es wäre besser, wenn du "external" nach Tools schaffst, damit die eigentliche Routinenarbeit von dem Script gemacht wird. Dann muss man nicht immer in "Config.in" rumfummeln, wenn man etwas anpassen will. Mir würde dies die Arbeit deutlich erleichtern, um dein "external" auf die Funktionen des "Outsourcers" zu erweitern, damit wir die beiden endlich zusammenführen können.
Welche Variablen fehlen dir denn? Sind sie nicht sowieso alle in ".config" oder wo anders gespeichert? Sonst würde ich entweder eine temp-datei dafür spendieren, oder gar eine (oder mehrere) config-Datei(en) unter tools/external generieren, die external-Script beim durchlaufen ausliest.
MfG
EDIT:
Wäre es nicht sinvoller, die Dateien irgendwo anders abzuspeichern als unter "build/modified/"? Wenn du external unter tools legst, würde ich dort oder gar im mod-Hauptverzeichnis ein Verzeichnis für ausgelagerte Dateien anlegen. Unter "modified" liegt das root-system welches ins flash gehört. Verzeichnis "external" unter "modified" verwirrt nur.
Code:
+ EXTERNAL_FILES="$EXTERNAL_OWN_FILES"
+ [ "$EXTERNAL_FREETZ_PACKAGE_LTRACE" == "y" ] && EXTERNAL_FILES+=" /usr/sbin/ltrace"
+ [ "$EXTERNAL_FREETZ_LIB_libart_lgpl_2" == "y" ] && EXTERNAL_FILES+=" /usr/lib/libart_lgpl_2.so.2.3.19"
+ [ "$EXTERNAL_FREETZ_LIB_libdevmapper" == "y" ] && EXTERNAL_FILES+=" /usr/lib/libdevmapper.so.1.02"
+ [ "$EXTERNAL_FREETZ_LIB_libelf" == "y" ] && EXTERNAL_FILES+=" /usr/lib/libelf.so.0.8.10"
....Mit Zielverzeichnissen muss man sehen. Eigentlich kann man es automatisieren: Aus dem Hauptpfad die Pfadangaben auslesen (z.B. "usr/lib" oder "usr/bin") und dann dem Hauptpfad dazuaddieren. Im Falle des RAMs würde der Hauptpfad "/mod" heißen, im Falle des USB-Sticks dann in etwa "/media/uStor01/external". Nach der Zusammensetzung hießen dann die Pfade (als Beispiel):
Code:
/mod/usr/bin/mc.bin
/media/uStor01/external/usr/bin/mc.binIch wäre an meiner Seite mit Outsourcer und Downloader damit einverstanden und du hättest auch auf dem USB-Stick einen LINUX-conformen Verzeichnisbaum, was bei mehreren Dateien nur von Vorteil wäre.
Es wäre besser, wenn du "external" nach Tools schaffst, damit die eigentliche Routinenarbeit von dem Script gemacht wird. Dann muss man nicht immer in "Config.in" rumfummeln, wenn man etwas anpassen will. Mir würde dies die Arbeit deutlich erleichtern, um dein "external" auf die Funktionen des "Outsourcers" zu erweitern, damit wir die beiden endlich zusammenführen können.
Welche Variablen fehlen dir denn? Sind sie nicht sowieso alle in ".config" oder wo anders gespeichert? Sonst würde ich entweder eine temp-datei dafür spendieren, oder gar eine (oder mehrere) config-Datei(en) unter tools/external generieren, die external-Script beim durchlaufen ausliest.
MfG
EDIT:
Code:
+ -------------------------- WARNING ----------------------------------
+ Move all the files from build/modified/external to your choosen
+ directory on the box BEFORE you flash the reduced image!Wäre es nicht sinvoller, die Dateien irgendwo anders abzuspeichern als unter "build/modified/"? Wenn du external unter tools legst, würde ich dort oder gar im mod-Hauptverzeichnis ein Verzeichnis für ausgelagerte Dateien anlegen. Unter "modified" liegt das root-system welches ins flash gehört. Verzeichnis "external" unter "modified" verwirrt nur.
Zuletzt bearbeitet:
Jup, ich wollte es nach tools/ schieben, aber zB die $EXTERNAL_ENABLED waren dann nicht nutzbar. Und wie ich die Daten aus den external.in auslesen kann ist mir leider auch nicht klar. Den Unterpfad immer fest vorgeben finde ich nicht gut, da dies für mein Upload-Skrip nicht mehr funktioniert (und es mir somit keinen Nutzen sondern Nachteil bringt). Wenn müsste es schon änderbar sein. Nur wie
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,724
- Punkte für Reaktionen
- 16
- Punkte
- 38
Wäre es nicht einfacher dein upload-Skript zu modifizieren? Das es auch in die Unterverzeichnisse eintaucht? Hast du es schon hier veröffentlicht oder willst du es nicht? Läuft es denn auf der Box oder umgekehrt?
Bitte beachte mein EDIT im Posting oben.
MfG
Bitte beachte mein EDIT im Posting oben.
MfG
Hm, ich fand eigentlich, dass das Verzeichnis besser unter "build/modified" passt, da dieses bei jedem make neu erstellt wird und die Dateien dort herausgenommen werden. Vorher war es immer direkt in der Wurzel. Das Kernel Image liegt auch dort (für eva/adam flash).
Das upload-Skript ist noch viel zu unsauber. Es sind feste IPs, Pfade, Benutzernamen und Passwörter für die verschiedenen Boxen drinnen. Bei Gelegenheit mach ich das noch.
Es funktioniert wie gesagt via ftp. Es nun rekursiv für die Verzeichnisse zu machen dürfte schon ziehmlich aufwendig sein. Und das nur damit die Ordnerstruktur schöner auf dem USB-Stick aussieh... ich weiss ja nicht.
Wie gesagt spricht nicht dagegen die Zielpfade individuell ändern zu können, das muss dann aber irgendwie im menuconfig einstellbar sein. Es muss mir nur jemand sagen wie
Wobei dies natürlich das ganze für viele zu kompilziert macht. Die Idee hinter "externel" war, möglichst einfach Dateien auslagern zu können.
Evtl könnte man 1 Option machen: Verzeichnisse "flach" oder "wie sie sind" auslagern. Was meinst du dazu?
Und wie kann man Werte aus den external.in bekommen?
Das upload-Skript ist noch viel zu unsauber. Es sind feste IPs, Pfade, Benutzernamen und Passwörter für die verschiedenen Boxen drinnen. Bei Gelegenheit mach ich das noch.
Es funktioniert wie gesagt via ftp. Es nun rekursiv für die Verzeichnisse zu machen dürfte schon ziehmlich aufwendig sein. Und das nur damit die Ordnerstruktur schöner auf dem USB-Stick aussieh... ich weiss ja nicht.
Wie gesagt spricht nicht dagegen die Zielpfade individuell ändern zu können, das muss dann aber irgendwie im menuconfig einstellbar sein. Es muss mir nur jemand sagen wie
Wobei dies natürlich das ganze für viele zu kompilziert macht. Die Idee hinter "externel" war, möglichst einfach Dateien auslagern zu können.Evtl könnte man 1 Option machen: Verzeichnisse "flach" oder "wie sie sind" auslagern. Was meinst du dazu?
Und wie kann man Werte aus den external.in bekommen?
Neueste Beiträge
-
Wie bekomme ich die IKEA FBs Rodret & Styrbar an das Fritz Gateway angemeldet ?!?
- Letzte: Quarkjoghurt
-
[Problem] CMake-Fehler bei googletest
- Letzte: JohnDoe42
-
Wahlscheibentelefon an FRITZ!Box 7590
- Letzte: Joe_57
-
Dect 350 Pushbenachrichtigung per App
- Letzte: Quarkjoghurt
-
FRITZ!Box 7590 - INHAUS - Smart24P1 - 7.90 - Sammelthema
- Letzte: Heisenberg2018
-
RogerRouter scheitert an 2FA?- Letzte: PeterPawn
